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(57) Abstract 



An etfa.Uw».ic credit risk detennaning and assessing method and system for use in a data prxxessing system ( 10) provides credn nsk 
information necessary for managing on- and off-balance sheet credit risks in financial institution. The method includes the steps of and the 
system includes the scructures for staging dau from a plurality of extemal sources ( 12) to fomi suged dau ( U). A pluralitx of dehnitions 
116) relating to the suged datt to form defined suged dau are esublished. Then, the defined sugcd dau is related 10 the dehnitions to 
form related and defined sta^ dau (18). A plurality of risk rating dau stnjctures <26) including current and histoncal nsk raung* are 
esubltshed to assocute with the related and defined suged dau. The method and i\itrm ihen calcuUtes a pluTaIir> of financial perfonnance 
measurements assocuted wich the related and defined suged dau ttrucrurrs 
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METHOD OF AND SYSTEM FOR DETERMINING 
AND ASSESSING CREDIT RISKS 



TF.rmJTCAL F TF.T.D OF THE INVENTION 

The present invention relates to a method of and 
system for determining and assessing credit risks and, 
5 more particularly, to an electronic credit risk 

determining and assessing method system for use in a data 
processing system having a plurality of interactive 
workstations and that provides credit risk information 
necessary for managing on- and off-balance-sheet credit 
10 risks in one or more financial institutions. 
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pArKHROUND OF THE TNVENTION 

The extension of credit still constitutes the 
principal risk confronting most banks. Credit loss 
remains the primary cause of bank failures and 
5 involuntary acquisitions. There are three primary 

factors contributing to this situation. First of all, 
there have been fundamental changes in the bank lending 
environment that change how a bank deals with credit 
risks. Secondly, banks have historically focused on 
10 ' managing individual credit transactions to ensure 

compliance with lending standards. Managing the risk of 
an individual transaction is, however, for the financial 
institution no longer sufficient by itself to manage 
credit risk. The risk in the portfolio must also be 
15 managed. Thirdly, bank monitoring systems and internal 

processes are oriented to historical banking practices 
and, in many cases, are inadequate to meet current needs. 

Fundamental changes in the institutional lending 
environment have also occurred. Until relatively 
20 recently, banks were characterized by lending departments 

that were staffed with long-term employees who knew their 
customers by name. Loan officers grew into their role 
through an apprenticeship- type process, and they operated 
under a well-defined set of rules. The personnel and the 
25 tasks changed relatively slowly. Similarly, the products 

were few, relatively fixed, and simple. Lending was more 
localized to customers the bank knew well . Losses were 
relatively unusual events in this environment. 

The situation has changed dramatically, particularly 
30 in the last ten to fifteen years. Banks are larger and 

far more geographically dispersed. Lenders are younger 
and- less trained, and turnover has increased. Moreover, 
these lenders have a far more complex set of products to 
sell in an intensely competitive environment to a 
35 dwindling number of corporate customers. 

There is less time to deal with credit problems as 
well. In the past, the deterioration of a credit could 
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take years. Now it may happen in months. Bankers need 
to anticipate problems, not just react to them. 

Focus on individual transactions has arisen. Credit 
risk for the bank is not so much the risk of a single 
5 transaction as it is the accumulated risk of a large 

portfolio of transactions. While it is important to 
ensure that a specific transaction meets the criteria 
established by the bank (collateral, financial ratios, 
valuations, etc.), simply ensuring that a transaction 
10 * meets the bank's lending criteria is no longer sufficient 
for complete credit risk management. The bank must 
understand how a large number of individual transactions 
might be exposed to a dominant risk which could cause 
many of them to fail. 
15 Understanding the risk in the portfolio means 

understanding and measuring exposures and concentrations 
in segments of the portfolio such as industry, geography, 
collateral type, customer size, currency, and so on. By 
understanding the characteristics of the customers and 
20 products, the bank can move to contain risk in segments 

of the portfolio. This ensures that problems in one area 
are contained and do not affect the total portfolio, much 
like the multiple compartments of a ship keep it afloat 
even if one or two compartments become flooded. 
25 Managing the risk of the portfolio of credits does 

not replace or minimize the need for sound management of 
the individual transactions. Neither one alone would be 
sufficient. In fact, managing credit risk at these two 
levels should complement and reinforce each other. 
30 Portfolio risk information can improve the assessment and 

pricing of an individual deal, and the improved 
transaction decisions will lead to a better portfolio. 

Inadequate monitoring systems and processes exist 
today, however. Since most banks' credit risk monitoring 
35 systems are focused on the transaction, not the overall 

portfolio, where aggregate portfolio information does 
exist, they mainly provide accounting-oriented dara. 
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i.e., arranged by general ledger accounts. Typically, 
only limited data is available that is arranged the way 
risk really exists. Moreover, the process to generate 
the needed information is often fragmented and non- 
5 systematic. The resultant data tends to be micro- level 

details on individual deals. 

The result is that pertinent questions about the 
portfolio and the inherent risks are hard to answer. 
With presently available technology, it is not practical 
10 'to ask many questions concerning risks. These include, 
for example, questions such as the following: What is 
our exposure to a particular industry and to individual 
customers within that industry across all areas of the 
bank? What is the risk profile of our portfolio? How 
15 does it vary by product? By officer? By branch? How 

geographically dispersed are our customers? What are the 
dominant risks in our portfolio? Do linkages exist among 
segments of our portfolio that reduce or increase risk? 
What are the trends of our nonperf orming assets by 
20 industry? By geography? By customer? What is our 

weighted average risk rating by officer? By industry? 
By customer? How has it changed over the last year? 
What are the trends in loans to highly leveraged 
companies over the last five years? How geographically 
25 diversified is our real estate loan portfolio? 

Even if bank management is not asking these 
questions, bank regulators increasingly are. When 
questions such as these need to be answered, the process 
most banks currently use to gather the necessary data is 
30 labor intensive, costly, reactive, and time-consuming - 

The resultant data is often, consequently, fragmented, 
incomplete, out-of-date, unreconciled, inconsistent with 
history, and not integrated. 

Clearly/ a solution is required. Such a solution 
35 should use not only data from all sources in the bank to 

take a portfolio view of credit risk, but also be able to 
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go to the level of detail necessary to understand 
individual transactions . 
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pTTMMARY O F THK TNVENTIQN 

In accordance with the present invention, a method 
and system for determining and assessing credit risks is 
provided that substantially eliminates or reduces 
5 disadvantages and problems associated with previously 

developed methods and systems for these purposes . 

The credit risk method and system of the present 
invention provides the information necessary to manage 
on- and off-balance-sheet credit risk in financial 
10 ' institutions. The invention provides unparalleled access 
to information on credit risk and exposure through user- 
defined views such as (1) customer and customer 
relationship, (2) industry, (3) geography, (4) collateral 
type, (5) currency, (6) regulatory classification, risk 
15 rating, (8) tenor of investment, (9) customer seasoning, 

(10) officer, (11) product type, (12) branch (13) 
customer delinquency, and (14) department and/or 
division. 

One aspect of the system of the present invention 
20 includes a user interface to set up, maintain, and 

operate the system in a data processing system 
environment. On-line reports and spreadsheet downloads 
can be requested and managed through the user interface. 
A data staging facility and translation control function 
25 help gather financial and statistical data from across 

all sources, then normalize, balance, edit, and reconcile 
that data. Definitions and relationships data structures 
set up and maintain data identifiers, segmentation 
dimensions, relationship roles, and hierarchies to be 
30 used by the credit risk system of the present invention. 

Risk ratings data structures store the current and 
historical externally-determined risk ratings attached co 
customers and instruments, and ultimately use the risk 
ratings as a basis to calculate expected losses and 
35 weighted average risk ratings. The present syster. also 

includes standards management data structures that 
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establish upper boundaries and target amounts of exposure 
and that report results against standards. 

The present invention includes a credit risk system 
ledger function to store the data in such a way as to 
5 allow reporting of credit risk information on any 

dimension or basis, using batch reporting and spreadsheet 
download facilities delivered with the system. Reporting 
tools are also included to request and deliver batch 
reports and spreadsheet downloads, as well as for ad hoc 
10 ' access through optionally available tools. 

A technical advantage of the present invention is 
that it assists a financial institution to reduce credit 
losses. With the present system, a user may identify the 
potential loss in a segment of the portfolio earlier, 
15 enabling proactive actions to be taken. The user may 

understand why losses have occurred in the past to, 
resultingly, focus lending in areas of lower or more 
manageable risk. 

Another technical . advantage of the present invention 
2 0 is that it provides improved processes to help manage 

credit risk. The user of the present invention may 
effectively set credit limits and monitor variances, 
price credit to reflect risk, and calculate loan loss 
provision more accurately. The present invention allows 
25 a user to establish common standards and vocabulary for 

credit risk management, thereby providing comprehensive 
customer credit risk history to loan officers. 

Still another technical advantage of the present 
method and system is that they provide improved strategic 
30 processes in the financial institution. Monitoring 

credit portfolio against strategic targets and credit 
policy objectives is readily achievable with the present 
invention. In addition, the financial institution may 
identify risks more precisely in new acquisitions and 
35 gauge shifts in portfolio risk patterns. 

A further technical advantage of the present 
invention is that it provides an improved ability for a 
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financial institution to respond to regulatory 
requirements. The method and system provide data for the 
increasing demands of regulators for concentration and 
expected loss reporting. With the invention, the 
5 institution can more easily show proof of internal 

controls, as well as report director and other insider 
loans more accurately. 

The credit risk method and system of the present 
invention directly address at least five critical credit 
10 * risk-related business issues: (1) concentration and 

'exposure identification; (2) regulatory reporting; (3) 
portfolio management and forecasting; (4) standards 
management; and (5) marketing and deal structuring - 
The present credit risk method and system help 
15 answer important concentration and exposure questions. 

The questions may include, for example, what is our 
exposure to a particular industry? To a particular 
customer? What is the risk profile of our portfolio? How 
does it differ by product? By officer? By branch? How 
20 geographically dispersed is our portfolio? How are we 

exposed through linkages of interrelated industries? Is 
a certain type of collateral excessively dominant in our 
portfolio? What is our total customer exposure by level 
and type of exposure (e.g., outstandings, committed, 
25 advised, unadvised)? What is our exposure by tenor of 

instrument? What are our nonperf orming assets by 
industry? By geography? By customer? and What are our 
classified outstandings by industry? By customer? By 
collateral type? 

30 For regulatory reporting, the credit risk method and 

system of the present invention is an valuable tool to 
assist in addressing regulators* questions about credit 
risk. Having a credible, documented single source of 
credit risk data helps smooth relations with regulatory 

35 agencies and speed responses to their requests. 

Portfolio management and forecasting is another 
function that the present system makes more practical. 
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This includes the analytical processes of using data from 
the present credit risk method and system to address 
questions of the following type: How has our portfolio 
mix changed by risk grade? By industry? By collateral? 
5 By geography? What are our forecasted loss and 

nonperf orming asset levels? How can we adjust our 
portfolio to balance our risk? How much of our portfolio 
could be securitized? What is the maturity profile of 
our portfolio? How do our loans to an industry segment 

10 ^ fall into various risk categories? 

The standards management features of the present 
invention enable the user to define specific targets or 
limits and to report actual results compared to these 
standards. The following kinds of questions are 

15 pertinent to the standards management functions: What is 

the exposure to a particular segment versus plan? Which 
units have more risk than others? Than the corporate- 
wide standard? Which units have exceeded limits in 
commitments to unseasoned customers? Do any segments of 

20 the portfolio exceed corporate policy guidelines? 

Marketing and deal structuring is the fifth key area 
where the credit risk method and system of the present 
invention may be valuable to answer questions such as the 
following: Where should we focus our credit extension 

25 efforts? How does our share of an industry compare with 

industry's share of the economy? How should we price 
risk? Is our portfolio priced properly to reflect risk? 
Where do we have a competitive advantage with respect to 
risk? Which products are we selling to which types of 

30 customers? 

The present invention, therefore, provides a wide 
variety of features and functions relating to the credit 
risks of a financial institution. The following 
description details are embodiments of the present 

35 invention which is recited in the appended claims. 



wo 96/30850 



PCTAJS96/04368 



10 

RPTKF DESCRTPTTQN OF THE DRAWINGS 

For a more complete understanding of the present 
invention and the advantages thereof, reference is now 
made to the following description which is to be taken in 
5 conjunction with the accompanying drawings in which like 

reference numerals indicate like features and wherein: 

FIGURE 1 shows a data processing system environment 
that may incorporate one or more embodiments of the 
present invention; 
1Q , FIGURE 2 illustrates the process flow of the present 

r embodiment as part of a data processing system; 

FIGURE 3 illustrates application of the data staging 
facility of the present embodiment, 

FIGURE 4 illustrates the ledger data file that may 
15 be used with the present embodiment of the invention; 

FIGURE 5 describes the existing applications, data 
staging facility, and ledger functions of the present 
embodiment ; 

FIGURE 6 describes the relational data store nature 
20 of the present embodiment; 

FIGURE 7 describes further organization of the 
ledger of the present embodiment; 

FIGURE 8 illustrates a user interface applicable to 
one or more applications of the present embodiment; 
2 5 V- FIGURE 9 describes the reporting process flow of the 

present embodiment; 

FIGURE 10 describes the process flow for the CRS 
ledger update functions of the present embodiment; 

FIGURE 11 provides the ledger process flow of the 
30 present embodiment of the invention; 

FIGURE 12 describes the various hierarchies 
available with the present embodiment of the invention; 

FIGURE 13 describes examples of the various product 
hierarchies of the present embodiment of the invention. 
35 FIGURE 14 describes conceptually the segmentation 

dimensions aspect of the present embodiment; 
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FIGURE 15 illustrates the association of the risk 
rating components of the present embodiment. 

FIGURE 16 describes the data flow for the risk 
rating customer functions of the present embodiment; 
5 FIGURE 17 illustrates the data flow for the risk 

rating instrument functions of the present embodiment; 

FIGURE 18 illustrates the results of expected loss 
calculations according to the present embodiment; 

FIGURE 19 illustrates the processing flow for the 
10 - CRS-tb-EAS interface functions of the present embodiment; 

FIGURE 20 illustrates the sequence and percentage 
split rating feature of the present embodiment; 

FIGURE 21 describes the process flow and 
associations for the assignment batch process aspect of 
15 the present embodiment; 

FIGURE 22 describes the assignment batch control 
card features and functions of the present embodiment; 

FIGURE 23 conceptually depicts the inherited rate 
feature of the present embodiment; 
20 FIGURE 24 illustrates the rating amount hierarchies 

applicable to the present embodiment of the present 
invention; 

FIGURE 25 describes the risk profile features of the 
present embodiment of the invention; 
25 FIGURE 26 describes the processing flow for the risk 

rating source and value maintenance function of the 
present embodiment of the invention; 

FIGURE 27 describes the processing flow for the 
customer risk rating maintenance functions of the present 

30 embodiment; 

FIGURE 28 describes the processing flow for the 
instrument risk rating maintenance feature of the present 
embodiment ; 

FIGURE 29 describes the data flow for the risk 
35 reporting process of the present embodiment; 

FIGURE 30 illustrates the processing flow for the 
risk reporting on-line feature of the present embodiment; 
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FIGURE 31 describes the processing flow for the risk 
reporting function of the present embodiment; 

FIGURE 32 illustrates an example of a segmentation 
dimension table of the present embodiment; 

FIGURES 33-36 describe certain aspects of various 
portfolio and mult i -dimensional reports of the present 
embodiment ; 

FIGURE 37 describes the processing flow for the 
customer detail report functions of the present 
' embodiment; 

FIGURE 3 8 illustrates conceptually the standard 
definition functions of the present embodiment; 

FIGURE 3 9 conceptually illustrates the application 
of the standard maintenance functions of the present 
embodiment ; 

FIGURE 40 describes the batch process functions of 
the standard maintenance feature of the present 
embodiment ; 

FIGURE 41 shows an example of the standard variance 
0 report of the present embodiment ; 

FIGURE 42 provides the data flow for the standard 
management functions of the present embodiment; and 

FIGURE 43 provides a processing flow chart of the 
standard maintenance, selection and assignment functions 
5 of the present embodiment; 

FIGURE 44 provides a processing flow diagram of the 
standards checking and reporting functions of the present 
embodiment ; 

FIGURE 45 illustrates the total exposure functions 
0 that the present embodiment makes possible; 

FIGURE 46 shows the results of a percent ledger 
function applicable to the standard maintenance aspect of 
the present embodiment; 

FIGURE 47 illustrates further the percent ledger 
.5 calculations of the present embodiment; 

FIGURE 48 illustrates the application of a standard 
limit amount in the present embodiment; 
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FIGURE 4 9 illustrates more completely the 
application of the standard maintenance functions of the 
present embodiment; 

FIGURE 50 provides a diagram of the logical data 
model for data structures of the credit risk system of 
the present embodiment ; 
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nP.TAII.ED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS 

Preferred embodiments of the present invention are 
illustrated in the FIGURES like numerals being used to 
refer to like and corresponding parts of the various 
5 drawings . 

FIGURE 1 shows data processing environment 10 for 
practicing the present embodiment of the invention. In 
FIGURE 1, sources of financial and statistical data 12 go 
to data staging facility and translation control function 
0 '14. Sources of characteristic and relationship data 16 
go to definitions and relationships function 18, The 
output of data staging facility and translation control 
function 14 and definitions and relationships function 18 
flows to data processing environment 2 0 of the present 
5 embodiment. Data processing environment 20 may include a 

system known as the earnings analysis system or EAS 22 as 
described in U.S. Patent Application Serial No. 
08/148,671 by Wainscott, et al . , and assigned to Hogan 
Systems, Inc. of Dallas, Texas. In addition, data 
\0 processing environment 20 may include budget and planning 

system 24 as described in U.S. Patent Application Serial 
No. (Baker & Botts File No. 18921-0106) , as well as the 
credit risk system 26 of the present embodiment and other 
systems 28 for financial management and control that the 
25 user may desire. Using personal computer user interface 

30 of data processing environment 20, numerous outputs 32 
are achievable as reporting tools including ad hoc 
reporting, batch reports, and spreadsheet downloads for 
management and analyses . 
30 Personal computer user interface 30 may use a 

standard IBM compatible personal computer and can be used 
for multiple applications within the bank in addition tc 
providing access to reports, spreadsheets, and 
maintenance 32. Information from the credit risk syster. 
35 and other applications may be downloaded directly to an 

end user equipped with Lotus 1-2-3* or Microsoft Excel' 
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for further analysis, formatting, and graphical 
reporting. 

Data processing environment 10 may also include 
products that use a graphical user interface (GUI) on 
5 . personal computer interface 30 to provide on-line 
functionality for establishing and maintaining the 
framework and rules governing processing for the various 
financial institution applications. The method and 
system of the present invention may be implemented as a 

10 ' single station environment or as a multi-station 
environment using a local area network (IiAN) 
configuration. In either configuration, users employ a 
communication link between the personal computers and the 
mainframe where the software and data reside. The LAN 

15 configuration is attractive for providing easy 

administration because only one copy of the instructions, 
data structures, and data files are required to service 
multiple workstations. In addition, individual window 
functions can include security to control user access. 

20 FIGURE 2 illustrates the process flow of the present 

embodiment as part of a data processing system to more 
particularly show the credit risk system 26 of FIGURE 1. 
As FIGURE 2 indicates, sources of financial and 
statistical data 12 and sources of characteristic and 

25 relationship data 16 go to data acquisition and staging 

function 34 which includes data staging facility and. 
translation control function 14 and definitions and 
relationship function 18. From data acquisition and 
staging phase 34, output goes to core processor 36 that 

30 supports the present embodiment to produce CRS ledger 38, 

risk ratings 40, and standards management results 42. 
Output from core processor 36 includes reporting cools 
32, as described in FIGURE 1. Personal computer user 
interface 30 permits the present embodiment of the 

35 invention to perform these functions. 

The credit risk method and system of the present 
embodiment, therefore., divides into three modules, or 
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functional areas, including risk reporting, risk rating, 
and standards management. The credit risk method and 
system provides, comprehensive credit risk information 
tailored to the unique characteristics of the financial 
5 institution or organization. The present invention 

serves as a tool to assist in the application of the 
institution's credit management policies and procedures, 
yet it does not impose any particular conventions or 
methodologies. The institution defines its business 
10 ' rules and operating environment for subsequent reporting 
~ and information retrieval. The present method and system 
■ also provide a management information system tailored to 
the specific management policies and procedures of the 
institution or organization. The present embodiment 
15 helps managers (1) identify exposure concentrations, (2) 

report and evaluate credit risk trends, (3) establish 
limits and targets for risk exposure, (4) define and 
create reports, (5) identify on- and off-balance sheet 
credit risk, and (6) . calculate expected loss. 
20 Source data used in the present system is collected 

from the institution's core application systems through 
extract programs. Any number of source applications as 
well as external commercially available data bases can 
provide data. Information may also be added on-line. 
25 This information can be dovmloaded to workstation 

- spreadsheet tools for further analysis and modeling to 
effectively manage the credit portfolio. 

The credit risk system is a powerful tool for 
gathering, manipulating, and reporting credit risk 
30 information. The description and linkage of data in the 

credit risk system or CRS ledger, which is a data base 
structure, are the foundations of the present credit risJ- 
system. The data description foundations involve data 
identifiers and segmentation dimensions. The data 
35 linkage foundations involve relationship roles and 

hierarchies. Each of these four foundations is describe 
below. 
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The present embodiment includes a definitions and 
relationships module or data structure that establishes 
and maintains the data identifiers, segmentation 
dimensions, relationship roles, and hierarchies which 
5 define the credit risk data. Typically, the data 

necessary to establish these definitions and relations 
comes from sources such as customer information systems 
and external data bases . 

A first foundation of the present system is the data 

10 . identifiers that the system uses. Each financial and 

statistical amount in one embodiment of the CRS ledger is 
described by seven identifiers. The data identifiers 
include the (1) reporting period which is the time period 
associated with the piece of data (e.g. month, quarter, 

15 etc.), (2) company as the entity in the bank's legal 

structure that "owns" the amount, (3) organizational unit 
as the department, cost center, branch, etc. within the* 
company, (4) customer which is the individual customer or 
a group of customers, (5) instrument which is unique 

20 obligation, note, or deal number, (6) amount type which 

is the piece of data is {e.g., a balance, participations 
bought and sold, contingent liabilities, a fee, etc.), 
(7) product as the specific type of product represented 
by the specific instrument. These identifiers are called 

25 primary identifiers and are dealt with uniquely in the 

credit risk system of the present embodiment - 

Another foundation of the present system are the 
segmentation dimensions that it provides. The 
segmentation dimensions relate to both the customers and 

30 instruments to allow the credit risk system user to 

partition the credit portfolio in as many ways as are 
needed. FIGURE 12 shows examples of segmentation 
dimensions that may be used in operating the present, 
embodiment of the invention. In essence, the capability 

35 to attach segmentation dimensions to both customers and 

instruments provides nearly unlimited potential to 
describe the data and to define the specific segments 
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that are suitable to analyzing the bank's credit 
' portfolio . 

A third foundation of the present embodiment is the 
relationship roles data structure. The relationship 
5 roles data structure of the credit risk system includes 

user-defined relationships that define certain data 
linkages. These linkages include linkages of 
(1) instruments-tq-of f icers, (2) instruments- to- 
organizations, (3) customers-to-customers , (4) customers- 
10 ' to-officers, and {5). customers- to-organizat ions . The 

vuser of the credit risk system first defines the type of 
relationship that can occur in each relationship role, 
then specifies the officer, organization, or customer 
filling that role. With relationship roles, the credit 
15 risk system user may aggregate exposure information by 

related customers for purposes such as legal lending 
limits, regulatory requirements, and other types of 
concentrations. 

A fourth foundation of the method and system of the 
20 present embodiment is the hierarchies data structures. A 

hierarchy data structure defines the "roll up" 
relationship of data. 

FIGURE 3 illustrates conceptually the external 
source to risk reports function of the credit risk method 
25 " and system of the present embodiment. Flow diagram 40 
illustrates external sources 42 providing inputs from 
many credit operations and systems in a bank to Data 
Staging Facility 14. Data staging facility 14 supplies 
the credit risk system of the present embodiment with 
3 0 data to produce reports 4 4 including, for example, 

multidimensional report 46, portfolio growth report 48, 
portfolio trend report 50, portfolio mix report 52, risk 
profile report 54, and standards report 56. 

As FIGURE 3 illus^trates , application of the data 
35 staging facility 14 serves the purpose of gathering, 

editing, balancing, translating, and normalizing raw data 
that is fed from multiple source applications into the 
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present credit risk system. In the preferred embodiment, 
data staging facility 14 is operated via personal 
computer user interface 30. The key functions that the 
data staging facility 14 performs are to reconcile source 
5 applications to general ledger accounts, balance by 

source application, translate raw data to user-defined 
data identifiers, translate foreign currencies, assign 
user-defined identifiers for missing data, edit 
identifiers and dates, and prepare raw data in the format 

10 - needed by the credit risk system core processor. 

Credit risk reports 44 are tabular formats which 
contain a title, an organizational context, and rows and 
columns of data. In the present embodiment, credit risk 
reports are available on-line for download to 

15 spreadsheets- The naming conventions of the reports are 

those of spreadsheets. For example, rows define the 
horizontal display of data, columns define the vertical 
display of data, and cells define the data at the 
intersection of a row and column. 

20 Implementing the credit risk system of the present- 

embodiment requires designing the end result, i.e., the 
reports 44, first and then defining the data needed to 
support the end result. However, it is necessary to 
understand the data stores and structures first to use 

25 all of the features and functions of the present 

embodiment . 

FIGURE 4 illustrates numerous data files that may be 
used with the present embodiment of the invention. 
FIGURE 4 illustrates the ledger data for multiple 

30 reporting years. FIGURE 4 shows ledger data for 1995 and 

1996. Each year an individual ledger record 60 
represents a single combination of organization, 
customer, instrument, and amount ID. For example, in 
FIGURE 4, ledger record 60 specifically includes the 

35 organization "FNB North, " the customer, "Ace 

Electronics," the instrument, "6853291," and the amounr 
identifier, "part sold." Note that ledger record 62 
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includes the organization, customer, and instrument that 
are the same as ledger record 60. The difference is that 
the amount identifier is "Principal" for ledger record 6 2 
instead of "part sold" of ledger record 60. Ledger 
5 record 64 contains the same combination as ledger record 

62, but is for the year 1996. Each ledger record 60, for 
example, contains up to 12 amounts, one for each period 
or month in the reporting year. Ledgers from previous 
years are retained for trend reporting and historical 
10 ' analysis. With the present embodiment of the invention, 
data is entered into the system in batch from source 
application extracts, input files from data staging 
facility 14, or may be entered on-line. The majority of 
data is entered in entered in the batch mode while a low- 
15 volume entry and maintenance may be performed on-line. 

FIGURE 5 describes the existing applications, data 
staging facility, and CRS ledger aspects of the present 
embodiment to more completely illustrate the concept of 
data from external sources 70 being placed into data 
20 staging facility 14 where the data is translated to a 

common set of identifiers and written to the data stores 
in CRS ledger 72. CRS ledger 72 includes definition and 
hierarchy data stores or structures. The data that the 
credit risk system of the present embodiment uses may be 
25 retrieved from CRS ledger 72 for reporting and analysis 

based on the relationships defined by roles and 
hierarchies such as instruments, officers, segmentation 
dimensions, customers, organizations, amounts, products, 
and hierarchies, as further defined below. 
30 An important aspect of the present method and system 

is the reporting and data store relationships. Credit 
risk financial data for the present embodiment is stored 
in the CRS (i.e., credit risk system) ledger which 
contains detail instrument - level information for the 
35 credit risk system. Each entry in CRS ledger 14 contains 

the appropriate structure for reporting year, 
organization, customer, instrum.ent, amount identifier. 
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and actual amount for each reporting period in the year. 
CRS ledger 14 is a relational data base with 
relationships between the data on the ledger and all 
other data in the credit risk system. To create a 
5 report, CRS ledger 14 is searched. Ledger records are 

selected based on the report criteria for report rows and 
columns. Other data segments related to the selected 
ledger entry are examined to determine if they match the 
criteria defined for the report. When a record is 
10 ' selected, the detail amounts are accumulated to produce 
the report . 

The editing, translating, and reconciliation of data 
for use with the present embodiment may be performed by a 
support system such as that one having the name 
15 Management Support System (MSS) by Hogan Systems, Inc. Of 

Dallas, Texas. The definitions and relationships for use 
in these steps may be established by the institution 
during implementation of the invention. The present 
method and system uses the following MSS data stores: 
20 (1) organization which includes two identifiers:, (a) 

company and (b) unit. A company is used to identify a 
legal entity such as a holding company, a bank within the 
company, or a bank. Multiple companies may be 
established on the system. A unit is a subset of the 
25 company and is defined based on a cost center, a branch, 

or any other desired type of unit within an enterprise. 
The same units may be identified in one or more 
companies. A customer usually corresponds to a legal 
entity such as a sole proprietorship, partnership, 
30 corporation, or formal joint venture with whom the 

institution has a business relationship. An instrument 
is a .document that represents a specific credit 
obligation. An officer is an individual who has specific 
responsibilities within the organization. Management 
35 information is reported by an officer's association to 

customers and instruments. A product is a specific type 
of credit or obligation. An amount defines various 
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balances such as unused commitments, total outstanding, 
guaranteed amounts, participations sold, charge off, non- 
performing, recover, or non-accrual. Segmentation 
dimensions are demographic or economic characteristics 
5 that provide risk information- Examples of segmentation 

dimensions are standard industrial classification codes, 
geography, instrument size, customer size scale, 
delinquency, geographic area, maturity or expiration 
date, and collateral. Segmentation dimensions are linked 
10 'to either customer or instrument. 

-1- CRS ledger 14 is the financial data store for credit 

: risk system of the present embodiment. CRS ledger 14 is 
made up of records containing the organization, customer, 
instrument, amount type, actual amount, and reporting 
15 period. This data is used to access all related 

information in the system. The risk rating data store of 
CRS ledger 14 contains rating sources, dates, rates, and 
the last assigned rating for each customer and 
instrument. The report definitions data store of CRS 
20 ledger 14 contains the report format and selection 

criteria for risk reports. The reports data store 
contains the actual reports that have been created. The 
reports for the information in this data store are 
available for on-line viewing. The standards data store 
25 contains the standards definition, and assigned limits or 

targets . 

FIGURE 6 describes the relational data store 
facility of the present embodiment. FIGURE 6 shows an 
example of a CRS ledger 72 relational data store 74. 

30 Relational data store 74 shows several ledger records 60. 

A ledger record 60 may be accessed if any one of its 
elements is known. Once a ledger record 6 0 has been 
retrieved, other databases may be accessed based on a 
relationship to any one of the elements in the retrieved 

35 record. For example, an officer may be retrieved based 

on the relationship to an instrument. 
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Two methods of defining and establishing 
relationships are provided with the present method and 
system. They are hierarchical and associative . 
Hierarchical relationships are used to establish 
5 relationships of individual items within a data type. 

Multiple hierarchies can be established to support 
different views of the portfolio at different levels of 
detail- An individual item may be included in many 
different hierarchies. Hierarchical relationships are 

10 - provided for organization, customer, product, instrument, 
amount, and segmentation dimensions. Associative 
relationships are used to connect related data. 
Predefined relationships are customer-to-customer, 
organization-to-customer, of ficer- to -customer, customer- 

15 to-segmentation dimension, organization- to- instrument , 

organization-to-officer, and instrument- to-segmentation 
dimension . 

FIGURE 7 illustrates the different sorts 76 of 
ledger records 60 organized according to the amount type. 

20 For example, ledger record 78 includes all records for 

organization "FNB North" with the customer of "Ace 
Electronics," and instrument "6853291" for which the 
amount type is "Principal . " Ledger record 80 includes 
the same data as ledger record 78, except the amount type 

25 is used exposure. Likewise, ledger record 82 is the same 

except for the amount type being "Oreo." In the present 
embodiment, each record on the ledger data table contains 
12 amount entries, one for each reporting period. A 
record is created for every amount type for an 

30 instrument. Financial data for an instrument is scored 

on CRS ledger 72 by reporting year and amount identifier. 
A separate record is created for each amount identifier 
associated with the instrument. 

FIGURE 8 illustrates a ledger window 90 that the 

35 present embodiment uses to add ledger records or change 

the amount on an existing record. Window 90 is provided 
for low-volume entry of new records or maintenance cf 
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existing amounts. If the data received from external 
sources is grossly incorrect, the exact process for 
inputting the data should be corrected and run again. 
However, ledger window 90 is a significant help in 
5 communicating between the user and the credit risk system 

of the present embodiment. The various fields of ledger 
window 90 relate to the various parameters of the credit 
risk system. 

FIGURE 9 shows an example of CRS ledger 72 reporting 
10 -as flow diagram 100. From a source 102, data goes to 
. edit process 104 and/or update process 106. From edit 
process 104, reports such as report 108 are generated. 
Likewise, from update process 106, reports such as 
reports 110 are produced. The edit and update process 
15 produces reports of ledger records that were rejected and 

reconciliation reports for use in balancing back to the 
input source. Detail reports 112 are produced by 
customer and instrument for use in analyzing the data on 
the system. Through report process 114, reports such as 
20 report 116 and report 118 are generated. 

CRS ledger 14 is created and updated by data input 
directly from source application extracts or input files 
created by the data staging facility of the present 
embodiment. Data enters the update function through the 
25 . batch editing process or the on-line maintenance window. 

The CRS ledger 14 update function provides a single entry 
point for all data posted to CRS ledger 14. Data is 
entered to the present system in the form of input 
records. Input records can be provided from source 
30 application extracts, input files from the data staging 

facility, or records can be entered on-line. The CRS 
ledger 14 update function consists of an edit process and 
a posting process. The edit process validates the 
identifiers on each input record. The posting process 
35 accumulates the edited input for an instrument and posts 

a total amount to CRS ledger 14. Reports are produced to 
identify exceptions and posted records. The on-line 
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maintenance window allows for corrections, adjustments, 
and low-volume input of application data. Data retained 
on CRS ledger 14 is the source of financial information 
for standards management and risk reporting. 
5 FIGURE 10 shows a flow chart for the primary 

processing functions and data flows within the CRS ledger 
update process of the present system. CRS ledger update 
data flow diagram 12 0 shows how data staging facility 122 
and source application data files 124 provide data to 

10 , batch editing module 126, Batch editing module 126 
operates with input from MSS definitions and 
relationships module 128. From batch editing facility 
126, ledger update processing exceptions report 13 0 and 
ledger update exception summary report 132 may be 

15 prepared. The results of batch editing module 126 are 

valid ledger records 134. Valid ledger records 134 go to 
CRS ledger update module 136. CRS ledger update module 
136 provides output to CRS ledger module 138, which also 
receives on-line posting entry module 140 output. From 

20 CRS ledger update module 136, reports including ledger 

updates source reconciliation report 142 and ledger 
update audit journal by source report 14 4 may be 
produced. CRS ledger module 13 8 provides data to ledger 
detail reporting module 146. Ledger detail reporting 

25 module 146 produces ledger detail by customer report 148 

and ledger detail by instrument report 150. 

CRS ledger update process 120, therefore, performs 
batch maintenance including the steps of editing the 
input transactions and performing database updates as 

30 well as printing exception reports. The CRS ledger input 

portion of the CRS ledger update facility edits input 
transactions and produces a file suitable for ledger 
updates. In addition, the functions of creating 
checkpoint data sets, editing input transactions, and 

35 printing processing reports are part of the CRS ledger 

input . 
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The CRS ledger update module 12 6 posts in two 
different ways depending on the period- For the first 
period in a new processing year, CRS ledger update module 
12 6 posts the edited input transactions to the CRS ledger 
5 138. Because there are normally a large number of new 

records at the beginning of a new processing year, these 
records are added using a database load utility such as 
DB2 Load. Duplicates rejected from this load are 
subsequently processed as updates. For the remaining 
10 ' periods of a year, there are a large number of updates 
- and relatively few added records. Input records are, 
therefore, posted as updates to existing ledger rows. A 
control card option is provided with the present system 
to insert new rows as the updates are processed or to 
15 write new records to a file that is subsequently loaded 

using a database load facility. During the CRS ledger 
update posting processing, numerous checks and backup 
steps may be performed and maintained in a share of the 
integrity of the data. 
2 0 The method and system of the present- embodiment 

permit both batch and on-line facilities for credit risk 
system processing. The approach used for batch 
processing is designed to minimize ongoing maintenance 
and to allow users to maintain a variety of data. Credit 
25 risk method and system of the present embodiment permits 

adding data types easily without requiring changes to 
existing programs. Moreover, the present method and 
system allows reuse of all required programs except the 
batch driver and on-line interface programs. In the 
30 present embodiment, programs are largely comprised of 

reusable programs written in generic COBOL II. 
Architecture of the present embodiment is sufficiently 
flexible to allow batch processing to be divided into 
multiple job streams that maintain different types of 
35 data. These job streams may be executed as required. 

In providing data for CRS ledger 14, each record is 
edited for valid identifiers. Edits are performed. 
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including editing the reporting period against pre- 
established definitions and relationships to ensure it is 
defined as a valid reporting period. The company 
identifier is edited against pre-established definitions, 
and relationships to ensure it is defined as a valid 
company. The unit identifier is edited against pre- 
established definitions and relationships to ensure it is 
defined as a valid unit identifier. The instrument 
identifier is edited against pre-established definitions 
- and relationships to ensure it is defined as a valid 
instrument. The customer identifier is edited against 
pre-established definitions and relationships to ensure 
it is defined as a valid customer. The amount' identifier 
is edited against pre-established definitions and 
relationships to ensure it is defined as a valid amount. 

Records with exceptions are rejected and reported on 
the Ledger Update Processing exceptions report 13 0, 
These records can be corrected and reentered on-line, or 
corrected and re- input into the batch editing process. 
On-line posting entry is also possible with the present 
embodiment. New CRS ledger 14 entries can be added on- 
line using the "Credit Risk Ledger" window. Fields are 
edited using the same edit criteria used for batch 
editing. Edits must be passed before an update occurs. 
Existing CRS ledger 14 entry amounts can be maintained 
on-line. The amounts entered replace the existing CRS 
ledger 14 amounts . 

If the reporting period and identifiers on an input 
record match an existing record, the amount from the 
input record replaces the amount already on CRS ledger 
14. A new record is created for the entry if an existing 
record is not found with the identical combination of 
identifiers. 

CRS ledger 14 detail reporting includes a batch 
facility that prints details of CRS ledger 14 upon 
request. Input to CRS ledger 14 is provided fror; 
existing transaction systems and is entered and 
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maintained using an on-line window or batch entry 
facilities. With the window facility, the on-line 
facilities record updates and maintenance information on 
the CRS Maintenance Journal. The batch facility, on the 
5 other hand, records all updates made through batch 

maintenance so that they appear on the CRS Maintenance 
Journal . 

The CRS ledger update function is primarily a batch 
process, however, the present invention provides a 
10 ' windows user interface for on-line entry of ledger 

updates. The present embodiment of the invention also 
uses the data staging facility that may be used to 
provide data for extract files that meets the required 
input format of the present system. 
15 FIGURE 11 illustrates the CRS ledger batch update 

flow process 160 of the present embodiment. The CRS/MSS 
databases 162 go to host data base requestor module 164. 
Data staging facility extract files 166 and application 
extract 168 are fed to input validation and edit module 
20 170. Host database requestors module 164 and input 

validation and edit module 170 communicate with one 
another. Input validation and edit module 170 provides 
data to exception report streams 172. Exception report 
streams 172 go to ledger exception reporting module 174. 
25 Ledge exception reporting module 174 generates ledger 

exception reports 176. 

Input validation and edit module 170 generate ledger 
posting report streams 178 and ledger posting records 
180. Ledger posting records 180 go to DB2 load module 
30 182 for use by CRS ledger module 184 in producing CRS 

ledger 186. For periods 1 through 12, ledger posting 
records 180 also go via DB2 load 182 to CRS loading 
posting module 184 to permit updating and possibly adding 
records where necessary. CRS ledger 184 serves as an 
35 input to ledger detail reporting module 188 in. producing 

ledger detail reports 190. Alsc, ledger posting report 
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Streams 178 go to ledger posting reporting module form 2 
to generate ledger posting reports 194. 

The CRS ledger batch edit function 160, therefore, 
processes the input records from the data staging 
5 facility using extract file 164 and optional external 

sources using application extract files 168, Each field 
is validated in input validation and edit module 170 for 
proper data attributes and CRS processing rules. Records 
passing these tests are written to CRS ledger posting 

10 ' records file 180 and are processed by this CRS ledger 

posting program of the present embodiment. Records that 
fail the test are reported on exception report streams 
172. These records must be corrected and reentered 
through the CRS batch edit function • Audit and 

15 reconciliation reports are produced from this step to 

allow validation against the original extracts. Records 
are read from the CRS ledger posting records file 180 
during the CRS ledger posting batch job step. The 
posting step updates the CRS ledger 186. Valid records 

20 from batch edit process 160 are read by CRS ledger 

posting module 184. The records are sorted to permit 
consolidation of like key records into a single database 
update. For the first period of a processing year, the 
initial posting run contains a large amount of data added 

25 with a new processing year key. For this reason, this 

initial posting run for the year performs a DB2 load 182, 
rather than performing record updates in place. 

For periods other than the first, the posting 
program checks a field in the posting record to determine 

30 to do an insert or an update. This indicator field is 

sent by the edit program after validating the fields on 
the record. Records to be inserted may be written to a 
sequential file for input to DB2 load utility 182. 

Any records that fail the insert and update steps 

35 are written to a sequential file for printing on a CRS 

ledger audit journal by source and CRS ledger source 
reconciliation report. The present embodiment includes 
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checkpoints that are taken at specific intervals to 
provide for job restart in case of system failure of an 
abort or end. Updates are committed when each checkpoint 
is taken. 

FIGURE 12 shows a data store by CRS ledger field 
according to one aspect of the invention. Data store 200 
includes organization, customer, instrument, amount 
identifier, amount, and date. Each instrument element 
202 of ledger record 200 has a direct relationship to 
V. instrument hierarchy data store 204, instrument data 
: store 206, segmentation dimension data store 208, risk- 
- rating data store 210, product data store 212, and 
relationships data store 214 including organization 
relationship 216 and officer relationship 218. 
15 The credit risk system of the present embodiment 

allows separate and alternate hierarchies to be 
established for organizational units, products, 
customers, instruments, segmentation dimension categories 
as defined by a financial institution, and the amount 
20 types. 

Each hierarchy can have up to twenty levels of roll 
up points. An unlimited number of alternate hierarchies 
are allowed which enable different views of the business 
to be taken dynamically without storing endless amounts 
25 — of data for every possible view desired. Reporting is 
possible at any combination of hierarchies and levels, 
providing enormous flexibility in viewing the credit 
portfolio. 

FIGURE 13, therefore, shows examples of the multiple 
30 product hierarchies available with the present 

embodiment. Different roll -up points and report 
information are produced by each hierarchy. Report rows 
are produced for each point on level below the hierarchy 
point selected for a report. The way a hierarchy is 
35 defined determines what will appear on the rows and 

columns of risk reports. For example, if in the 
hierarchy Report A, as indicated by column 220, 
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selected, and the hierarchy point total outstanding 222 
is further selected, the resulting report will contain as 
many as six rows, including any commitments, letters of 
credit, commercial loans, consumer loans, mortgage loans, 
5 and home equity loans. On the other hand, if hierarchy 

Report B, as indicated by column 224 with total exposure 
hierarchy 226 selected, two rows of data will be 
generated, including information from commercial loans 
row 228 and commitments row 230. Commercial loans may 

10 * include term loans, time loans, real estate loans, and 

demand loans. Commitments may include letters of credit 
such a regular or standby letters of credit as well as 
revolving lines, 

FIGURE 14 shows examples of segmentation dimensions 

15 that the present embodiment provides. For example, 

segmentation dimensions 24 0 may include dimensions such 
as officer 242, tenor 244, as well as the other various 
dimensions in FIGURE 12. Mult iple- segmentation 
dimensions may be attached to a customer or an 

20 instrument. Dimensions and categories within a dimension 

are user-defined and may be input from existing source 
applications. Relationship roles are available to relate 
customers to other customers, officers to organizations, 
and instruments to officers and organizations. 

25 Relationship roles are uniquely defined by combination of 

predetermined relationship rule types and user-defined 
relationship role codes in the present system. 

Risk rating permits institutions to apply a risk 
assignment to each customer and credit instrument. The 

30 risks are rated on a scale of 1 to 10 (1 being the lease 

risk and 10 the greatest risk) and an expected loss 
percent for each rating. The expected loss percent is 
used to calculate the expected loss amount which may be 
passed to an external system such as the Earnings 

35 Analysis System (EAS) by Hogan Systems, Inc. Customer 

and instrument ratings from multiple risk rating sources, 
such as credit administration, officer, and regulators. 
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can be entered and maintained. Rules can be defined for 
each rating source to determine if a rating by the source 
is required, allowed, or not allowed. A credit 
instrument may be rated for the full exposure amount, or 
5 may carry split ratings. For example, the portion of the 

exposure that is secured or guaranteed may be rated with 
a lower numbered rating than an unsecured portion. An 
assignment process examines each rating for customers and 
instruments and selects the most severe of the ratings. 
10 —The assigned rating is used for risk reporting. 

The risk rating module of the present credit risk 
system includes two major functions: (1) provide for the 
entry and housing of externally determined risk ratings 
(by instrument and customer) and the expected loss rates 
15 associated with each risk rating level; and (2) assign 

the appropriate risk rating that provides the foundation 
to calculate potential loss based upon user-defined rules 
and to develop risk profiles of portfolio segments. 

Two elements are fundamental in the analysis of 
20 portfolio credit risk. These elements are the amount to 

which the financial institution is exposed and the risk 
of loss associated with that exposure. Risk rating is 
the quantification of the estimated risk of loss that is 
associated with credit exposure. The composite risk 
25 associated with a financial institution's credit 

portfolio can be expressed as a weighted average risk 
rating derived from individual risk ratings assigned to 
each of its credit extensions. Risk ratings provide a 
consistent standard of measurement used to track problem 
30 credits, anticipate future losses, and ultimately, take 

credit risk into account when measuring profitability. 

■ The credit risk method and system cf the present 
invention also provides for the entry and housing of 
externally determined risk ratings for both customers and 
35 instruments. Instrument ratings are used to calculate 

the potential loss associated with exposures and to 
develop risk profiles of the portfolio or portfolio 
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segments. Customer ratings, which are typically used as 
baselines for determination of instrument ratings, are 
maintained for reference purposes only. 

FIGURE 15 illustrates the primary processing 
5 functions and data flows within risk rating. The 

processes within the risk rating function can be 
categorized as risk rating controls, risk rating of 
customers, and risk rating of instruments. Risk rating 
controls include the definition of valid risk rating 

10 'Sources and risk rating values. Risk rating of customers 
and risk rating of instruments include facilities for 
maintenance of externally determined source risk ratings, 
reporting of missing required source ratings, and 
assignment of most severe risk ratings for use in 

15 portfolio risk analysis. 

The conceptual illustration of FIGURE 15 shows the 
risk rating components of the present invention. In 
relationship diagram 250, source files 252 are shown to' 
go to customer rating module 254 and instrument rating 

20 module 256. Rating values files 258 also go to customer 

rating module 254 and instrument rating module 256. 
Instrument rating module 256 also provides the ability to 
provide spit-rate analysis and reporting. From the 
customer rating module 254 and instrument rating module 

25 256, missing rating process 262 determines what ratings 

are missing and responds to inputs from instrument 
hierarchy 264, product files 266, and ledger module 268. 
Missing ratings process 262 outputs to assignment process 
module 270 which together with missing ratings process 

30 module 262 produces missing ratings report 272, 

exceptions report 274, and assignments report 276. 

.Sources 252 that may provide risk ratings for 
customers and instruments are predefined by the 
institution before customer or instrument ratings can be 

35 entered. The present embodiment also includes a risk 

rating source window that defines valid rating sources 
and establishes processing control parameters related to 
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each source. Examples of risk rating sources that may- 
provide ratings are officer, credit review, and 
regulator. Sources are user defined, and source rules 
can be defined for each source code for both customer and 
5 instrument. The source rules are, for example, a rating 

by this source is: -Required, -Allowed, -Not allowed. 
An option designates whether ratings by this source are 
normally included or excluded from consideration by the 
rating assignment process. Individual customer or 
0 \ instrument ratings from this source may override the 

V source rule for inclusion or exclusion from consideration 
_ by the assignment process . 

Available window actions allow a user to add a new 
risk rating source code, its associated description, and 
.5 its related customer and instrument risk rating controls. 

A user may also delete an existing source code and its 
associated description and controls. Furthermore, a user 
may modify the description, customer risk rating 
controls, or instrument risk rating controls for an 
0 existing source code. Edits prevent deletion of a risk 

rating source that is currently utilized in a customer or 
instrument risk rating. 

According to the component relationships of FIGURE 
15, therefore, a customer or instrument risk rating is 
>5 entered to the system of the present embodiment from 

either an extract or from on-line input. This rating is 
edited against the source rules and the rating values. 
Missing ratings process 262 identifies customers and 
instruments that do not have a rating by a source that is 
10 required to produce a rating. Assignment process 270 

selects the rating from the highest risk of both 
customers and instruments. The assigned rating has an 
'associated risk amount. The assigned rating and rated 
amount are used for risk reporting. The credit risk 
35 system of the present embodiment, therefore, provides the 

standard rating values, definitions of rating sources, 
common rating processes, and expected loss calculations. 
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The use of a defined scale of risk rating values 
provides a systematic, consistent, and credible framework 
for assessing risk. The system enhances uniformity 
through all units, divisions, and affiliates and is 
5 compatible with regulatory definitions. It provides the 

ability to distinguish the various defined levels of risk 
as well. Risk rating sources 252 which may contribute 
risk ratings for customers and instruments are predefined 
to the present system. This establishes uniform rules 
10 ' throughout all units, divisions, and af filiates . 

The present operating system also provides for 
external entry and maintenance of risk ratings for both 
customers and instruments. Customer ratings are 
maintained for reference and to assist in determining the 
15 rating for instruments for which the customer is 

responsible. Rules attached to each rating source 
determine if a rating is required by the source, if the 
source rating may be overridden, and if ratings by the 
source are candidates for rating assignment. For the 
20 present embodiment, a batch process analyzes all ratings 

for each customer and each instrument and selects the 
most severe (i.e., the worst case) rating as the assigned 
rating for the customer or instrument. 

Risk rating rules can be defined by product. This 
25 permits, for example, setting a rating at a line-of- 

credit or facility level, and having drawdowns inherit 
that rating. Another option is to require that a risk 
rating must be entered for all instruments associated 
with the product. Instruments may be rated on a full or 
30 a split amount basis. For example, split risk racings 

may be used to differentiate the risk of loss associated 
with collateralized versus uncollateralized portions of 
an outstanding exposure amount. Split ratings can be 
defined as sequenced amounts or as percents. 
35 Multiple user-defined sources can be identified as 

valid for contribution of customer or instrument risk 
ratings. Examples of risk rating sources that rr.ight be 
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established are officer, credit audit, regulator, or a 
segmentation dimension (for example, the country of 
risk) . One risk rating per source is allowed for a given 
customer or instrument . Control parameters allow the 
5 institution to designate whether a rating by a particular 

source is required, allowed, or not allowed for customers 
or instruments. Reports of missing required customer or 
instrument ratings are provided. Risk ratings are 
effective dated and are retained for historical 
10 information reporting and analysis. 

Input to the risk rating function is entered and 
- maintained using on-line windows or a batch record 
facility. Using the windows facility, the on-line 
facilities record updates and maintenance information on 
15 the CRS Maintenance Journal. The windows include (1) 

risk rating source, (2) risk rating value, (3) customer 
risk rating, (4) instrument risk rating, and (5) 
instrument split risk rating. 

Using the batch facility, all updates made through 
20 batch maintenance are recorded and appear on a 

maintenance journal that the system produces. The batch 
processes in the risk rating function assign a rating for 
each customer and instrument. The most severe rating is 
designated as the assigned rating and is used for 
25 - reporting, portfolio analysis, and calculation of 
--^ expected loss amounts. Risk rating source control 

parameters allow the institution to specify whether a 
source is to be included or excluded from consideration 
in the risk rating assignment process. The institution 
30 can also determine, by source, if the entered risk rating 

control option can be changed for a particular customer 
or instrument. 

Control parameters allow the institution to 
designate all or a subset of 10 possible rating values as 
35 valid for use, and to provide its own description for 

each designated rating. A loss percent may be associated 
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expected potential loss amounts. 

FIGURE 16 shows the risk rating customer data flow 
for analyzing the customer and risk rating databases to 
5 determine the rating that should be assigned to a 

particular customer. This process also updates the 
customer -assigned risk rating database with that 
information. The steps that the risk rating customer 
data flow diagram 280 of FIGURE 15 perform include (1) 

10 * determining the risk rating that should be assigned to a 
customer, (2) updating the assigned customer risk ratings 
database, (3) reporting on assignments made, and (4) 
reporting on assignment exceptions. 

In process flow diagram 280 of FIGURE 16, customer 

15 risk rating module 254 receives input from risk rating 

values module 258, batch customer ratings module 252, on- 
line rating window 284, and risk rating sources module 
252. Risk rating sources module 252 also provides input 
to customer missing ratings analysis module 286. 

20 Customer risk rating module 254 provides customer risk 

ratings 288 to customer risk rating assignment module 
290. Customer risk rating module 254 also may produce 
customer ratings exceptions report 292. Customer 
missing-ratings analysis module 286 also provides 

25 information for customer risk ratings 288. Customer risk 

rating assignment module 290 produces assigned customer 
risk ratings 294 as well as reports such as customer 
rating assignment exceptions report 296 and customer risk 
rating assignment report 298. Customer missing- rat ings 

30 report 300 also comes from customer missing- rat ings 

analysis module 286. In summary, risk rating cuscomer 
data flow process 280 yields an updated assigned customer 
risk ratings database and customer assignment report data 
streams. The reports from this process include customer 

35 risk rating assignment report 298 and customer assignment 

exceptions report 296, as well as customer missing- 
ratings report 300. 
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The customer risk rating function allows for the 
entry and maintenance of customer risk ratings provided 
from multiple sources. One rating is allowed per source 
for a given customer. With the present embodiment, 
5 customer risk ratings are input on-line, using the 

customer risk rating window, or using batch facilities. 
Each customer rating includes the source code, the 
rating, and a comment to annotate the rating. The date 
the source determined the rating is retained for 
10 ' reference. An indicator defaults to the customer rating 
.'^ from the source rules to determine if the rating is to be 
included or excluded by the risk rating assignment 
process . 

Available window actions allow a user to (1) add a 
15 new source rating entry for a customer, (2) delete an 

existing source rating entry for a customer, and (3) 
modify the rating value, comment, date, or exclusion 
information on an existing customer source rating entry. 
Customer missing required source rating analysis 
20 permits an institution to identify one or more risk 

rating sources as required to provide a risk rating for 
each customer. This specification is made through the 
risk rating source function. The customer missing 
required source rating analysis process identifies and 
25 - reports exceptions to the required source rating policy. 

Batch control parameters are provided for specification 
of the officer and organization relationship roles that 
are used for report totals. This process is executed in 
batch, on request. In the process, each customer is 
30 examined to determine if risk ratings by each of the 

required sources are present . 

• Through the customer risk rating assignment process, 
the most severe of the risk ratings provided for each 
customer is determined, and that rating is designated as 
35 the assigned customer risk rating. All source ratings 

for a customer are considered candidates for assignment 
unless specifically identified for exclusion on che 



wo 96/30850 



PCT/US96/04368 



customer risk rating entry. The candidate source rating 
that has the highest value on the 1 to 10 scale is 
selected as the assigned risk rating. If the highest 
value is shared by multiple candidates, the latest dated 
5 source's rating is assigned. If no candidate source 

ratings are found for a given customer, no rating is 
assigned to the customer being processed. Batch control 
parameters provide specification for the report sequence. 
These parameters include the reporting period, the 
0 ' officer relationship role, and the organization 

relationship role. When a customer risk rating is 
assigned, it is dated with the reporting period date so 
that assignment risk rating history is available. 

FIGURE 17 shows process flow diagram 310 for the 
5 risk rating instrument data flow process of the present 

embodiment. Instrument risk rating assignment process 
310 analyzes the instrument and instrument risk rating 
databases to determine the rating that should be assigned 
to a particular instrument. The steps that the 
0 instrument risk rating assignment process performs 

include (1) determining the risk rating that should be 
assigned to an instrument, (2) updating the assigned risk 
ratings database, (3) reporting on assignments made, and 
(4) reporting on assignment exceptions. 
5 FIGURE 17, therefore, shows that risk rating values 

258 and risk rating sources 252 go to instrument risk 
rating module 256. In addition, batch instrument ratings 
312 and on-line rating window inputs 284 go to instrument 
risk rating module 256. Output from instrument risk 
0 rating module 256 include instrument rating exceptions 

report 314 and instrument risk ratings 316. Instrumenc. 
risk .ratings go to instrument risk rating analysis module 
318, as does output from risk rating sources 252. 
Instrument risk ratings go to instrument risk rating 
5 assignment module 320. Instrument risk rating assignment 

module 320 produces an assigned instrument risk 322 and 
report, including instrument rating assignment exceptions 
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report 324 and instrument risk rating assignment report 
326. Instrument-missing-rating analysis module 318 
produces instrument -missing- rating report 328. In 
summary, therefore, the outputs of risk rating instrument 
5 process 310 include an updated assigned instrument risk 

rating database, instrument risk rating assignment report 
326, and instrument rating assignment exceptions report 
324. These reports may be printed according to 
instruction reports of the present system. 
1Q ' With the present embodiment, entry and maintenance 

of instmjment risk ratings can be provided from multiple 
sources. One rating is allowed per source for a given 
instrument. Instrument risk ratings are entered on-line 
using the "instrument risk rating" and associated 
15 instrument split risk rating windows, or using batch 

facilities. The source for each instrument risk rating 
entry is selected from the valid sources defined through 
the risk rating source function of the present 
embodiment. Only sources that have been identified as 
20 required or allowed for contribution of instrument risk 

ratings are presented for selection. The instrument for 
which the rating is provided is specified and must be a 
valid instrument. The initial setting of the exclusion 
indicator, and whether override of the setting is allowed 
25 on the rating entry, is determined by the instrument risk 

rating controls established through the risk rating 
source function. 

Available window actions allow a user to (1) add a 
new source rating entry for an instrument, (2) delete an 
30 existing source rating entry for an instrument, and (3) 

modify the rating, comment, date, or exclusion 
information on an existing instrument source rating 
entry , 

An institution can identify one or more risk rating 
35 sources as required to provide a risk rating for each 

instrument. This specification is made through the risk 
rating source function. In addition to instrument 
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ratings being required from a source, a risk rating for 
the instrument may be required by the product. This 
specification is made using the product definition 
function. The instrument missing required source rating 

5 analysis process identifies and reports exceptions to the 

required source rating policy. 

Through the instrument risk rating assignment 
process, the most severe of the source risk ratings 
provided for each instrument is determined, and that 

0 ' rating is designated as the assigned instrument risk 

rating. The instrument risk rating assignment process is 
executed in batch at the conclusion of each reporting 
period, following updates to instrument source ratings 
and exposure amounts, to update the assigned instrument 

5 risk rating data for the current reporting period. All 

source ratings for an instrument are considered 
candidates for assignment unless specifically identified 
for exclusion on the instrument risk rating entry. If no 
candidate source ratings are found for an instrument and 

0 the product is defined as required, the rating of a 

superior instrument from that source is used. 

Batch control parameters are provided for 
specification of (1) the reporting period for which 
assignments are made, (2) the hierarchy identifier of the 

5 instrument hierarchy used in the assignment process, (3) 

the amount hierarchy and hierarchy point linking amounts 
used to define rated exposure amounts, and (4) the 
relationship role of the officer and organization to be 
used for reporting of risk rating assignments and risk 

0 rating assignment exceptions. These parameters include 

the reporting period, the officer relationship roie, and 
the organization relationship role. This process is 
executed in batch, on request. In the process, each 
eligible instrument is examined to determine if risk 

5 ratings by each of the required sources are present or 

can be inherited from a higher level instrument in the 
PRIMARY instrument hierarchy. 
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All source ratings for an instrument are considered 
candidates for assignment unless specifically identified 
for exclusion on the instrument risk rating entry. When 
all candidate risk ratings are for the full exposure 
amount, the candidate source rating that has the highest 
rating value on the 1 to 10 scale is selected as the 
assigned risk rating. If the highest value is shared by 
multiple candidates, the latest dated source's rating is 
assigned. 

I . - If a required source rating is not found for an 

instrument and there is an instrument at a higher level 
in the instrument hierarchy designated for use in risk 
rating assignment, the source rating assigned to the 
higher level instrument is considered for assignment. 
S This process is referred to as inheritance. If there is 

no related instrument at a higher hierarchy level or if 
no rating from the source is found at a higher level, an 
exception is reported. 

For the present embodiment, expected loss amounts 
0 may be calculated in a batch process. The processing 

criteria defined to the batch process are definition of 
the reporting period end date, the amount identifier, and 
the amount identifier hierarchy which is to be selected. 
If an amount identifier hierarchy is identified, the 
5 ^ specified amount identifier and all subordinate amount 
identifiers in that hierarchy are to be selected. To 
illustrate this concept more completely, FIGURE 18 shows 
an example of expected loss calculations. In FIGURE 18, 
expected loss calculations may produce a table such as 
0 Table 330 listing organizational field 332, product field 

334, customer field 336, instrument field 338, amount 
identifier 340, rate 342, expected loss fxeld 344, and 
amount field 346. From this data, table 348 is produced 
including expected loss field 344. instrument amount 
15 field 346, and expected loss amount 350. These results 

are summarized in table 352 for organization field 354 as 
"First Bank North," product field 356 as "Product," 
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customer field 358 as "Ace Electronics," and total 
expected loss amount field 360 as "21,374." 

The example of FIGURE 18 includes an expected amount 
that is calculated for the principal balance of the 
5 customer, "Ace Electronics, " with commercial loans at 

"First Bank North." The expected loss is calculated by 
selecting all matching amounts from ledger 72, 
identifying each instrument represented, assessing the 
rated exposure amount for each rating for the instrument, 

10 ' multiplying the expected loss factor for the rating times 
the rated exposure amount for each instrument selected, 
and creating a summary record for input to an external 
system such as EAS . 

For each record selected, the amount of expected 

15 loss for the instxoiment is calculated by multiplying the 

rated amount by the expected loss percent. The batch 
process of the present embodiment totals the expected 
loss amounts for each combination of organization, 
product, and customer to create an input record for EAS, 

20 for example. A report is produced by the system 

including instrument detail and customer totals that are 
created for input to a profitability system. The amount 
hierarchy identifier and amount identifier are 
calculating the expected loss amount and creating the 

25 input for EAS are preferably the same as those selected 

for the risk rating process. 

Expected loss calculation calculates expected loss 
amounts for each amount entry on the ledger that meets 
user-defined processing criteria. The processing 

30 criteria, entered as batch parameters, include the 

reporting period end date and the amount identifier used 
in selection of records from the ledger. An amount 
identifier may be specified alone to indicate that only 
records with that identifier are selected, or an amount 

35 identifier hierarchy may be identified to indicate the 

specified amount identifier and all subordinate amount 
identifiers in that hierarchy are included for selection. 
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The risk rating values table is accessed for each 
ledger record selected based on the instruments rating 
value to obtain the expected loss factor. The amount of 
expected loss for the instrument is calculated by 
multiplying the ledger amount by the expected loss factor 
and an output record is created containing the original 
instrument data plus the calculated expected loss amount . 
After expected loss amounts have been calculated for all 
selected ledger records, the expected loss amounts are 
'.passed to the generation of posting input process. 
_z The Earnings Analysis System (EAS) is a companion 

^application to the Credit Risk System in the Enterprise 
Management Solutions (EMS) family of systems all of which 
are made and sold by Hogan Systems, Inc. of Dallas, 
; Texas. EAS is described and claimed in U.S. Patent 

Application Serial No. 08/148,671, which is here 
expressly incorporated by reference. EAS measures the 
contribution to overall profit attributable to various 
organization units, products, and customers, and allows 
0 multi-dimensional reporting of profitability results 

along these lines. A fundamental element in the 
measurement of profitability is the accurate reflection 
of expenses. Among the expenses that are critical for 
identification in EAS are the expected loss amounts on 
5 exposures associated with particular organizations, 

products, and customers. The method and system of the 
present embodiment fulfills this critical information 
need by providing accurate expected loss amounts to EAS 
for incorporation in profitability calculations and 
0 calculation of risk-adjusted return. 

The credit risk system of the present embodiment 
carries detailed information at the instrument level. 
However, EAS carries detail information at the customer 
level. This process summarizes instrument detail for a 
\S customer and provides a single input record for each 

combination of organization, product, and customer in 
preparation for entry into EAS. 
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An expected loss percent can be defined for each 
rating. The expected loss percent is used to compute 
potential loss. A batch process calculates the expected 
loss amount and creates an input file for EAS . The 
calculation of expected loss is performed at the 
instrument level based on the assignment risk rating 
attached to an instrument and the user-defined loss 
factor. Customer risk ratings are held in the credit 
risk system for reference and reporting purposes. 

For uses of EAS, the calculated expected loss can be 
fed directly into profitability calculations. This is a 
far more accurate way to compute loan loss provision at 
an instrument detail level than simply allocating a total 
bank-wide reserve to instruments, products, customers, or 
organizational units. 

FIGURE 19 provides the processing flow for the CRS- 
to-EAS interface. Referring to FIGURE 119, processing 
flow diagram 370 shows that risk rating values table 3 72, 
CRS ledger table 374, and assigned instrument risk 
ratings table 322 provide information for CRS-to-EAS 
interface module 376. Expected loss calculation input 
parameters module 378 provides input parameters to CRS- 
to-EAS interface module 376. Outputs from CRS-to-EAS 
interface module 376 go to CRS-to-EAS posting journal 
streams module 380 and EAS ledger posting records module 
382. CRS-to-EAS posting journal streams module 380 
provides an input to CRS-to-EAS ledger posting report 
program 384 so that it may generate CRS-to-EAS posting 
journal report 386. As block 388 indicates, output from 
EAS ledger posting records module 382 goes to the EAS 
system associated with the host processor. In summary, 
therefore, CRS-to-EAS interface 370 of the present 
embodiment accepts control card values and then reads the 
CRS ledger to create the output sequential files for EAS 
and the ERS interface reports. Posting journal 386 of 
this interface documents the extract file created in CRS 
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and passed to EAS to allow EAS processing to balance 
similarly to other EAS application extracts. 

Expected loss factors input through the risk rating 
value function are used to calculate the expected loss 
for each instrument. Translation parameters are used to 
select instruments from the ledger by amount identifier 
to use in the generation of the EAS posting input 
process. These translations must be consistent in both 
products to ensure correct posting. 

After the instrument records have been collapsed 
-into a single EAS input record per customer, the records 
, are passed to the EAS ledger posting process for posting 
to the EAS ledger. The CRS-to-EAS posting journal 
reflects the individual CRS ledger 14 records and the 
15 summarized amounts for EAS posting. Input to the EAS 

Integration function is created and maintained through 
batch processing. 

FIGURE 20 illustrates the instrument split risk 
rating feature of the present embodiment. An instrument 
risk rating may be designated as full or split. When the 
rating type split is selected, the split method may then 
be selected from the options of sequenced or percentage. 
Sequenced split rating provides the ability to enter the 
ratings and the amounts for each rating. The sequence in 
25 - which the rates are entered and displayed is the sequence 
in which the base amounts will be produced by the risk 
rating assignment process. Percent risk rating provides 
the ability to split the exposure amount by defining the 
percent assigned to each rating. The percents entered 
30 must total 100 in the present embodiment. In FIGURE 20, 

the examples of split rating include a table 390 for the 
sequence split rating and table 392 for the percentage 
split rating. For a given instrument "6853291." Rates 
7, 8, and 9 may be selected for the sequence split rating 
35 to produce the amount examples of 70,000, 20.000. and 

10.000. The percentage split rating indicates for the 
same rates 7, 8. and 9 percentages of 70. 2C. and 10. 
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When one or more of the candidates is a set of 
split -amount risk ratings, the current exposure amounts 
associated with each rating split are calculated based on 
the base amount sequence or percentage distribution 
5 specified on the instrument risk rating entry • After 

current exposure amounts have been calculated for a split 
ratings, the assignment is made based on the following 
rules: First of all, if a full rating is equal or worse 
than the worst rating of a split-amount, the full rating 

10 ' is used. Secondly, if a full rating is better than the 
worst rating of split-amount, ignore the full rating and 
assign split ratings. Thirdly, the worst rating is found 
and the split -amount is selected as the assigned split 
rating. If the worst rating is in more than one group, 

15 select the one with the highest exposure amount. 

Further, if the exposure amounts are equal, select the 
group with the worst rating for the next highest amount. 
If exposure amounts and ratings are equal in multiple 
groups, select the latest dated rating. 

20 When the assigned rating is selected for an 

instrument with a split rating, the rating amounts are 
calculated based on the split method. For both sequenced 
and percentage methods, the amounts on CRS ledger 14 that 
match the amount hierarchy and hierarchy point on the 

25 batch control parameters are accumulated. For the 

sequence rating method, the accumulated ledger amount is 
applied in ascending sequence number order (the order in 
which the sequenced rates and amounts are displayed) . 
For the percentage rating method, the rated amount for 

30 each rate is calculated as the split percent times the 

accumulated amount . 

FIGURE 21 shows the rating assignment batch flow of 
the present embodiment. In particular, batch process 402 
receives instructions from customer process 280 and 

35 instrument processed 310. In addition, a control card 

input 404 may be provided to batch process 402. The 
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result of batch process 4 02 reports include assigned 
report 406 and not assigned process 408. 

The risk rating assignment process, therefore, 
examines each ratings for customer or instrument and 
5 selects the most severe rating as the assigned risk 

rating. All source rating for an instrument are 
considered candidates for assignment, unless a rating 
identified for exclusion on the instrument risk rating 
entry 310. When all candidate ratings are identified, 
10 ' the candidate source rating which has the highest rating 
; value on the 1-10 scale is selected as the assigned risk 
rating. If the highest value is shared by multiple 
candidates, the latest date and sources rating is 
assigned. 

15 FIGURE 22 shows the assignment batch control card 

404 of FIGURE 19 in more detail. The assignment batch 
control card 404 includes the period end date, the 
officer role code, the organization role code, the 
instrument hierarchy identifier, the amount hierarchy 
20 identifier, and the amount identifier. The risk rating 

assignment process is executed in batch at the conclusion 
of each reporting period following updates to ratings, to 
update the risk rating data for the report period. Note 
that in the present embodiment, if the assignment process 
25 is not executed, the risk reports for the current 

, reporting period will be based on data from the previous 
reporting period. 

FIGURE 23 shows the inherited rates aspects of the 
present embodiment. Inherited rates hierarchy 410 has as 
30 its highest element instrument "234589" which has an 

associated rate 412. This associated rate 412 may be 
used by next lower instruments. Such an instrument would 
be instrument "5434242," as block 414 depicts, which 
itself may provide a rating for instrument "3431323," as 
3 5 block 416 depicts. Also, for example, instrument 

"343234" may inherit from the instrument associated with 
block 412 a rating, as block 418 illustrates. This 
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rating may also go to lower-level instrument "523423," as 
block 420 depicts. Plus, if no candidate source ratings 
are found for an instrument and there is a related 
instrument at a higher level in the instrument hierarchy, 
the rating assigned to the higher level instrument is 
assigned by the system of the present embodiment. On the 
other hand, if there is no related instrument at higher 
hierarchy level, no rating is assigned to the instrument. 

With the inherited rate concept in mind, FIGURE 24 
'illustrates the rating amount hierarchies. Risk ratings 
are, therefore, assigned based on a selected hierarchy 
point such as an amount identifier as block 422 of FIGURE 
24 describes, within a selected amount hierarchy. If an 
instrument, as field 424 describes, does not have an 
amount in the selected amount hierarchy for the selected 
hierarchy point or its children (i.e., lower- level 
instruments) in the hierarchy, no rating will be 
assigned. If an instrument has two or more amounts, as 
field 426 depicts, in the selected hierarchy among the 
selected hierarchy point and its children, the amounts 
will be added together for the rating. 

When one or more of the candidates is a set of split 
risk ratings, the current exposure amounts associated 
with the ratings split are calculated based on the base 
amount sequence or percentage distribution specified on 
the instrument risk rating entry. After current exposure 
amounts have been calculated for split ratings, the 
assignment is made based on the following rules: (1) if 
a rule rating is equal or worse than the worst rating of 
0 a split amount, the full rating is used; (2) if a full 

rating is better than the worst rating of a split amount, 
the system ignores the full rating and assigns the split 
ratings; (3) if two different sources have split ratings, 
the system selects the one with the highest rating among 
5 its splits; (4) if the highest rating among the splits is 

equal, Che system selects the source with the highest 
exposure amount at the highest rating; and (5) if the 
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full rating is still equal to the worst rating of a split 
amount, the system continues to the next highest rating 
to select the most severe source. As FIGURE 22 
describes, therefore, the rating that is assigned for 
$150,000 is based on the amounts indicated by amount 
field 366. 

The table in FIGURE 2 5 describes the risk profile 
reports of the present embodiment which gives information 
segregated by ten risk ratings plus a weighted average 
' risk rating (WARR) . The risk profile reports of the 
-present embodiment display the risk grade categories for 
„ the designated context and row definition. Reports 
contain a column for each of the ten risk ratings, a not - 
rated column for instruments which do not have a risk 
5 rating, and a WARR for each row. Data is selected for 

the risk profile reports by matching the report request 
definition and the ledger data. When a match is found, 
the instrument is accessed to locate the assigned risk 
rating and associated rated exposure amount. Instruments 
0 are assigned a column based on risk rating. If an 

instrument does not have a risk rating, it is assigned to 
the not rated column. Rated exposure amounts were 
determined when the risk rating assignment process was 
executed. Rated exposure amounts were split as required 
>5 . among multiple ratings when split ratings are in effect. 

FIGURE 26 shows a processing flow diagram for the 
risk rating source and value maintenance aspects of the 
present embodiment. As processing flow diagram 430 
depicts, risk rating sources window 432 provides an input 
30 to risk rating sources maintenance module for 434. Risk 

rating values window 436 provides an input to risk rating 
values maintenance module 438. Outputs from risk rating 
sources maintenance 434 generate risk rating sources 
table 440 and part of EMS maintenance journal table 442. 
35 EMS maintenance journal table 442 also receives inputs 

from risk rating values maintenance module 438. Risk 
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rating values table 372 is generated by risk rating 
values maintenance module 438. 

Risk rating is the assignment of numeric values 
corresponding to the relative risk of loss for associated 
customers or instruments. These ratings provide a 
consistent standard of measurement by which to track 
credit problems, anticipate future loss and to account 
for credit risk when measuring profitability. The method 
and system of the present embodiment support a 10 -point 
'scale of risk rating values, where 10 is the worst rating- 
and one is the best. An institution may use all or a 
subset of ten values and assign its own description to 
each rating value. 

Risk ratings may be overridden for individuals 
customers or instruments where allowed by the 
definitions. Risk rating sources are defined by the user 
to control whether risk ratings by those sources are 
required, allowed, or not allowed for customers or 
instruments. As FIGURE 20 indicates, split risk ratings 
may be assigned to instruments for which the total 
exposure is broken down into multiple categories. For 
example, if a loan is only partially collateralized, the 
portion that has the collateral may receive a lower or 
better rating than the portion that has no collateral . 

The present embodiment includes an interface between 
its internal modules and files and an external product 
such as the earnings analysis system or EAS of Hogan 
Systems, Inc. in the form of an expected loss calculation 
by the present system for posting on EAS ledger. This 
expected loss calculation is performed by using amount 
fields from the CRS ledger of the present system for 
customers and instruments selected. The instrument risk 
ratings are selected from the assigned instrument risk 
ratings table. The amount fields are multiplied by the 
expected loss percent and selected from the risk rating 
values table for the assigned risk rating frorr. the 
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assigned instrument risk ratings table. This produces 
expected loss amounts per instrument . 

After all instruments for a given customer have been 
selected, the total amount becomes the EAS posting amount 
passed to EAS for that customer and processing begins for 
the next customer. After all customers have been 
processed from the CRS ledger, the total amount posted to 
EAS is reported to the CRS-to-EAS posting journal. This 
amount is passed to EAS for posting and is only used for 
' presentation. 

FIGURE 27 illustrates one embodiment of the customer 
risk rating maintenance processing flow diagram 450. As 
processing flow diagram 450 illustrates, risk rating 
values table 442, customer risk ratings batch input 
module 4 52, customer risk rating maintenance window 4 54 
(through customer risk rating maintenance GUI module 
456), and risk rating sources table 440 all provide 
inputs to customer risk rating maintenance edit module 
458. Risk rating sources table 420 also provides an 
0 input to customer missing risk rating module 460. 

Customer risk rating maintenance edit module 4 58 produces 
customer risk rating exceptions strings 462 and customer 
risk ratings table 288. Customer risk ratings exceptions 
strings 462 go to customer risk rating exceptions report 
5 program 464 for producing customer risk rating exceptions 

report 466. Customer risk ratings table 248 and customer 
hierarchy table 468 go to customer risk rating assignment 
module 470 for generating assigned customer risk ratings 
table 294. Output from customer risk rating assignment 
0 module 470 also joins with customer missing required 

source rating streams 472 that customer missing risk 
rating module 46 0 produces to generate customer risk 
rating report strings 474. Customer risk ratings report 
strings 474 go to customer risk ratings report driver 476 
S that generates customer missing required source rating 

report 478, customer rating assignment report 480 and 
customer rating exceptions report 482. 
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FIGURE 28 shows processing flow diagram 4 90 for the 
instrument risk rating functions of the present 
embodiment. As processing flow diagram 490 depicts, risk 
rating values table 372, instrument risk ratings batch 
input 492, instrument risk rating maintenance window 494 
(through instrument risk rating maintenance edit module 
496) and risk rating sources table 440 provide inputs to 
instrument risk rating maintenance edit module 4 98. Risk 
rating sources table 440 also provides an input to 
'instrument missing risk rating module 500. Instrument 
risk rating maintenance module 498 generates outputs 
including instrument risk rating exception streams 502 
and instrument risk ratings table 316, as well as 
instrument split risk ratings table 504. Instrument risk 
rating exception strings 502 go to instrument risk rating 
exception report program 506 to produce instrument risk 
rating exceptions report 508. Instrument split risk 
ratings table 504 and/or instrument risk ratings table 
316 go to instrument risk rating assignment module 320. 
Instrument risk rating assignment module 320 also 
receives an input from instrument hierarchy table 510. 
Output from instrument risk rating assignment module 320 
includes assigned instrument risk ratings table 512 and 
instrument risk rating report strings 514 which also 
receive input from instrument missing risk rating module 
500. Instrument risk rating report strings 514 go to 
instrument risk ratings report driver 516 to produce 
reports including instrument missing required source 
rating report 518, rating assignment report 520, and 
rating exceptions report 522. 

From processing flow diagram 450 of FIGURE 27 and 
processing flow diagram 490 of FIGURE 28, it is readily 
apparent that on-line risk rating maintenance includes 
creating risk rating sources and values and setting 
customer and instrument risk ratings. These functions 
may be performed with the preferred embodiment using 
associated on-line windows user interfaces. Customer and 
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instrument risk ratings may be entered in batch, also, 
using sequential input files. This process uses a batch 
maintenance driver in the preferred embodiment. An edit 
program validates the input for completeness and 
correctness as it relates to consistency with previously 
input definitions. Successful updates are reported on 
the maintenance journals, and errors are reported on the 
maintenance exception reports. 

Rating assignment is a batch process with the 
present embodiment that assigns risk ratings to customers 
or instruments. Risk ratings are possible with multiple 
rating sources, but only the highest is assigned to the 
customer or instrument. If no rating is found for. an 
instrument, the rating may be inherited from a higher- 
level instrument in the specified hierarchy. Customer 
ratings are not inherited. If no rating is assigned or 
inherited, the item is reported on the customer or 
instrument risk rating assignment exceptions report. 
Each customer or instrument that has a risk rating 
assigned appears on the customer or instrument risk 
rating assignment report. Output from the customer and 
instrument risk rating maintenance processes are 
specified above. 

The following discussion describes in yet further 
detail the substance of the previously identified 
.reports. Customer risk rating exceptions report 466 may 
include input records that contain exceptions and that 
were by-passed by the customer risk rating batch process. 
Customer missing required source ratings report 478 lists 
customers that are missing customer risk ratings as 
determined by the customer risk rating analysis batch 
process. Customer risk rating assignments report 480 
lists risk ratings that were assigned from among 
candidate risk racings during the customer risk rating 
assignment batch process. Customer risk rating 
assignment exceptions report 482 lists input records tha 
contained exceptions and that were by-passed by the 
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customer risk rating assignment batch process. The 
present embodiment provides the necessary facilities for 
correcting exceptions that occur in these processes. 
Instrument risk rating exceptions report 508 lists input 
records that contained exceptions and were by-passed by 
the instrument risk rating batch process. Instrument 
missing required source rating 518 includes customers 
that are missing customer risk ratings as determined by 
the instrument risk rating analysis batch process. 
* Instrument risk rating assignments report 520 lists risk 
ratings that were assigned from among candidate risk 
ratings. Furthermore, instrument risk rating assignment 
exceptions report 522 lists input records that contained 
exceptions and were by-passed by the instrument risk 
rating assignment batch process. Also, the present 
embodiment provides the necessary facilities for 
correction of exceptions arising in the above missing and 
exceptions reports. 

The credit risk method and system enables a user to 
0 establish a set of predefined reports that can be 

selected from a menu and that are updated automatically 
for each reporting period. This section outlines the 
mechanisms for creating, processing, and accessing 
reports . 

5 The system of the present invention offers two 

methods for defining and creating reports, A first 
method is through the use of report formats which include 
templates that allow the user to define key 
characteristics of reports. Second, a report generator 

0 permits design and production of tailored reports. The 

present system also facilitates modeling. The reports 
generated from this type of analysis enable the user to 
access data through a spreadsheet . 

The report formats a template that can be modified 

5 to address a wide array of portfolio analysis questions. 

These modifications enable the user to select the 
particular organization or officer that the report 
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addresses, to sort the organization's or officer's 
portfolio according to a particular hierarchy and a point 
(or points) within that hierarchy, to select an amount, 
and to define the rows and cells of the report. 
5 Each institution can define and create its own 

specific formats to meet reporting requirements not 
covered by the delivered formats. These tailored reports 
can be defined for regular production each reporting 
period. Reports are produced during a scheduled 
10 'background process that may be run on request. An 
example set of reports is provided for use in 
installation testing. These examples illustrate various 
reporting views and can be used as models for custom 
report development. Reports are typically produced for, 
15 each reporting period. However, they may be produced 

more frequently (for example, to review preliminary 
results for a reporting period) . 

Reports can be grouped into categories . For 
example, growth and marketing reports or concentration 
20 reports may be produced. The user-defined report 

identifier creates report categories that control the 
sequence in which reports are displayed on report 
selection windows. 

Any report that appears on the menu can be displayed 
25 in a Lotus 1-2-3 or Microsoft Excel spreadsheet where 

printing, charting, or modeling may be performed. The 
full functionality of the spreadsheet can be used to 
modify, create calculations, print, and save modified 
spreadsheets to a local drive . 
30 Reports can be defined for both spreadsheet and hard 

copy print. The spreadsheet version of a report can be 
downloaded on request and the hard copy versions can be 
routed to a report distribution system for printing and 
distribution. Reports are available for on-line viewing 
35 until the user-defined expiration date. 

Credit risk reports of the present embodiment are 
defined using predefined formats that are designed to 
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answer a wide array of questions about the portfolio. 
Reports are created by selecting criteria to produce 
custom reports . . 

The predefined report formats include: (1) Risk 
5 profile format for providing information segregated by 

ten risk ratings plus the weighted average risk rating, 
(2) portfolio mix to provides composition information by 
number of customers and financial amount, (3) portfolio 
growth which includes comparisons between two time 
10 'periods by number of customers and financial amounts, and 
(4) portfolio trend for providing information for the 
last eight quarters plus the current reporting period. 

Another risk report format of the present embodiment 
is the multi-dimensional format which provides 
15 information about one dimension that is also subdivided 

by another dimension. Risk reports may include, for 
example, formats such as industry-by-customer sales size, 
product -by-organization, maturity-by- instrument size, or 
any combination of user-defined dimensions. 
20 The report formats of the present invention provide 

the ability to define the information required for 
monitoring and analysis of portfolio changes. New 
reports can be created by selecting a report format and 
defining the selection criteria for the rows, columns, 
25 and cells of the report. A single format can be used to 

create many different reports by altering the selection 
criteria. Reports may also be downloaded in a Lotus 1-2- 
3 or Microsoft Excel spreadsheet, for example. The full 
functionality of the spreadsheet tools may then be used 
30 to chart, calculate, model, modify, and save spreadsheets 

to a local memory device. 

FIGURE 29 shows risk reporting process data flow 
that the method and system in the present: embodiment 
provide. FIGURE 29 shows the risk reporting process data 
35 flow diagram 530 for illustrating primary processing 

functions and data flows within the risk reporting 
functions of the present embodiment. From CRS ledger 
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186, risk rating data files 532 and MSS definitions and 
relationship files 534, data goes to batch reporting 
extract module 536. Output from batch reporting extract 
modules 536 includes report extracts 538 which go to 
batch report production module 540. Batch report 
production module 540 permits input from runtime 
variables entry facility 542 and generates risk reports 
spreadsheets 544 and risk reports hard copy 546. Report 
definitions 548 go to batch reporting extract module 536 
' and batch report production module 540 as inputs from 
report definitions module 550 in response to report 
definition windows facility 552. 

FIGURES 3 0 and 31 show processing flow diagrams for 
risk reporting according to the present embodiment. In 
FIGURE 30, processing flow diagram 560 for the on-line 
report set-up may begin with batch report request module 
562 communicating with batch report request GUI 534. 
Application report variables 566 also communicates 
instructions and results of instructions to application 
report variables GUI 568. In processing flow diagram 
560, report format definitions 570 go to DB2 load module 
572 to produce report format table 574. Report format 
table 574 goes to report format SQL module 576 to 
generate an input to batch report request GUI 564. Data 
flows between batch report request GUI 564 and report 
^_ definition edit module 578, Report definition edit 

module 578 also communicates with report definition SQL 
module 580, which itself communicates with report 
definition table 582. Application report variables GUI 
568 communicates with batch report requesc GUI 564 and 
application report variables edit module 584. 
Application variables report edit module 584 communicaces 
with both report definition SQL module 580 and report 
run-time variables SQL 586. Report run-time variables 
J5 SQL 586 also communicates with report run-time variables 

table 588. 
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For the batch report set-up, the processing flow 
appears in flow diagram 590 of FIGURE 31. As FIGURE 31 
describes, report format defined variables 592 
communicates with report I/O modules 594. Also, purge 
5 processor 596 communicates with report results files 598 

which receive data from spreadsheet load process module 
600. Spreadsheet load process module 600 receives input 
from report -in-process processor 602. Report -in-process 
processor 602 communicates with reports- in-process file 

10 '604, report I/O modules 594, and receives information 
from reports -in-process load files 606 and CQS report 
modules 608 . Spreadsheet load process module 600 also 
receives its spreadsheet load 610 from CQS report modules 
608. CQS report modules 608 also produces summary risk 

15 reports 612. Report I/O modules 594 provide inputs to 

report trigger extracts module 614 for producing report 
triggers 616. Report triggers 616 go to JCL build module 
618 which produces reports in process load 6 06 and report 
executing JCL file 620. Report executing JCL file 620 

20 goes to CQS reports module 608. CQS report modules 608 

produces detail reconciliation reports 622 and 
communicates with ledger qualification module 624. Also, 
CQS report modules 608 receives ledger extract 626. 
Ledger qualification module 616 responds to the 

25 definition and relation extracts 628 and risk ratings 

extract 630. Definitions and relationships extract 628 
is the output from MSS extracts module 632 which uses MSS 
definitions and relationships table 634. CRS ledger and 
risk ratings file 636 serves as an input to CRS extract 

30 modules 638 for producing risk ratings extract 630 and 

ledger extract 626. 

Risk reporting supports the ability to examine 
exposure for an individual customer, a portion of the 
portfolio, or the entire portfolio- Reports are defined 

35 to select actual exposure information to use as the basis 

for modeling. Reports are created using definitions, 
relationships, and reporting periods from the MSS data. 
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Reporting consists of three interrelated steps. The 
first step involves the specification of common report 
characteristics such as report format, report identifier 
and title, reporting medium, report frequency, and 
5 retention period. The next step, report definition, 

provides for user determination of specific report 
content. The last step, report selection, follows actual 
batch creation and allows the user to view reports on- 
line. 

10 ' Reports are defined on-line using report formats. 

The information supporting the reports is consolidated in 
a background process and made available for on-line 
^ viewing as well as printed for distribution. Reports can 
be defined for scheduled processing once each reporting 
15 period or for one time processing on request. Scheduled 

processing is typically run once each reporting period. 
Multiple report production requests can be processed in 
one reporting period. Each scheduled production cycle 
replaces the reports created by previous requests for the 
20 same reporting period. Unscheduled processing is run on 

request and can be requested for past or current 
reporting periods. Unscheduled processing can be for a 
one time report or to produce a scheduled report for a 
prior period. Automatic production of scheduled reports 
25 may be started or stopped by setting a schedule frequency 

indicator. On-line viewing of reports is initiated by 
selecting a context, a report title, and a reporting 
period. 

Reports are defined using report formats. The 
3 0 report formats are designed for a spreadsheet or a 

tabular presentation of information. The format 
structure provides the ability to define the information 
required for monitoring and analysis of portfolio 
changes. New reports are created by selecting a report 
35 format and the criteria for rows and cells. A single 

report format can create many different reports by 
altering the information selected for rows and cells. 
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Report print options provide the ability to request 
that reports be produced for a spreadsheet or hard copy. 
Reports may be produced for both of these options. 
Production of a detail report is requested from the 

5 report definition windows. The detail report provides 

the individual amounts summarized for the portfolio 
reports. Reports are defined using the maximum amount 
size contained in the data. The amount print size can be 
custom tailored by the institution. Reporting of 

0 liistorical amounts is based on historical CRS ledger 14 

information. In addition, customer and instrument 
segmentation classifications are reported as they were 
during the period reported. The present hierarchy 
configurations are used for rolling up totals. Reports 

5 are defined by selecting a report format and identifying 

the information required to produce the report. A report 
definition requires a report identifier, a report title, 
an organization or officer, an amount id, a hierarchy 
type, and a row definition. 

0 FIGURE 32 shows an example of a segmentation 

dimension table according to one aspect of the present 
embodiment . A customer or instrument may have one or 
more occurrences of segmentation categories within the 
same segmentation dimension. For example, a customer may 

•5 have many industries, one of which is designated as 

primary. If primary is selected, only those categories 
marked primary will be included in the report. If 
primary is not selected, all segmentation categories are 
reported . 

^0 For example, referring to FIGURE 32, if primary is 

selected, instruments "6853291" and •'2340986" are selected 
for a specified amount. If primary is not selected, 
instruments -6853291," -2340986,' and -9320687" are 
selected for the total amount. 

J5 FIGURE 33 illustrates the portfolio mix report 

variations that the present embodiment provides. The 
portfolio mix report gives composition infcrmatior. by 
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number of customers and financial amount. The portfolio 
mix report displays the number of customers and ledger 
amount for an organization and the selected segment of 
the portfolio. Data is selected for the report by 
matching the report request definition and the ledger 
data. When a match is found, the instrument record is 
selected and accumulated for the report . If a customer 
has more than one instrument selected for each role, the 
customer is counted only once. The present embodiment 
* provides a portfolio mix definition window for preparing 
-and generating portfolio mix reports. 

FIGURE 34 shows the portfolio growth data variations 
that the present embodiment provides. The portfolio 
growth report gives comparisons between two time periods 
i by number of customers and financial amount. The 

portfolio growth report displays the current customer 
count and financial amounts, the change between the 
beginning and ending periods, and the percentage of 
change. Data is selected for the report by matching the 
0 report request definition in the ledger data for the 

beginning and ending reporting periods. When a match is 
found, the record is selected and accumulated. After all 
matches have been accumulated, the change between the two 
periods is calculated. If a customer has more than one 
5 - instrument selected for each row, the customer is counted 
only once. The present embodiment also provides a 
portfolio growth report definition window for generating 
the portfolio growth report. 

FIGURE 35 illustrates the portfolio trend data 
to variations that the present embodiment provides. 

Portfolio trend reports give information for the last 
eight quarters, plus the current reporting period- The 
portfolio trend reports display the information by 
organization or officer. Data is selected for the 
IS reports by identifying the current reporting period, 

calculating the reporting period fcr the last eight 
quarters, and matching the report request definition and 
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the ledger data for the unnotified reporting periods. 
When a match is found, the record is selected and 
accumulated for the report. Ledger records will be 
selected by the present embodiment for reporting periods 
5 that are on the ledger. It is not necessary, therefore, 

that a record be on the ledger for all eight of the 
report quarters . The present embodiment provides a 
portfolio trend report definition window for generating 
the portfolio trend report. 

10 ' FIGURE 36 shows the multi-dimensional data 

variations applicable to the present embodiment of the 
invention. Mult i -dimensional reports give information 
about one dimension (e.g., industry) subdivided by 
another dimension (e.g., customer sales size). The 

15 mult i -dimensional reports provide the ability to cross- 

hatch segments of the portfolio. In all other formats, 
the columns are predefined. For multi-dimensional 
reports, the user defines both the columns and the rows. 
Data is selected for the reports by matching the report 

20 request definition and the ledger data. When a match is 

found, the instrument record is selected and accumulated 
for the report. The present embodiment provides a multi- 
dimensional report definition window for generating the 
multi-dimensional report. 

25 FIGURE 37 illustrates the customer detail report 

processing flow diagram 64 0 of the present embodiment for 
creating and displaying a customer exposure report to a 
user. Customer detail report processing flow diagram 64 0 
illustrates data base 642 providing input to customer 

30 detail report program 644 that communicates with GUI 

processing program 646. GUI processing program 646 
communicates with report display window 648 and customer 
detail report request module 650. The customer detail 
process produces a detailed listing of a requested 

35 customer and all that customer's relationships with the 

data base. The data includes MSS shared type data as 
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well as data directly applicable to the credit risk 
system of the present embodiment. 

Standards management allows the institution to 
establish limits or targets for various types of 
5 exposures. Standards may be established for the entire 

portfolio, or a specific segment of the portfolio. 
Standards are established as a target, which represents 
amounts to be achieved for the desired levels of exposure 
recommended, or as a limit, which represents the upper 
10 * boundary of exposure permitted. Standards may be 

-assigned as an amount or as a percent of the portfolio 
segment. For standards that are assigned as a percent, 
the standard amount is calculated as a percent of the 
total exposure amount for the standard- Targets may be 
15 established to encourage a particular area of credit 

exposure that the institution has identified as an 
opportunity for diversification or market penetration. 
Limits may be set to establish thresholds that are not to 
be exceeded without exception review. 
2 0 The standards management module of the present 

embodiment provides a means to establish limits that 
define an upper boundary of exposure and targets that 
define a desired level of exposure. These targets and 
limits can be established for organization, product, 
25 - -customer or segmentation dimension within its 

-organization. Variance reports are produced to show 
actual results versus established results. 

FIGURE 38 shows conceptually the standard definition 
process flow 660 of the present embodiment. Beginning 
30 with the target limit as block 662 depicts, the target or 

limit is applied within an organization context as block 
664 describes- Then, based on a designated organization 
standard definitions are applied to customer, 
organization, segmentation, or product, as block 666 
35 depicts- Based on calculations occurring with respect to 

block 666, amounts and percents are generated by the 
present system as block 668 describes. 
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The present method and system provides the ability 
to establish and monitor standards for the entire 
portfolio or for a specific segment of the portfolio. 
Standards may be set as either targets or limits. Both 
5 targets and limits may be expressed as a fixed amount or 

as a percentage of the portfolio being managed. As block 
662 depicts, standards are established as a target which 
represents amounts to be achieved for the desired levels 
of exposure recommended or as limits which present the 

10 ^ upper boundary of exposure permitted- Per block 664, 

standards are defined by on-line windows, in the present 
embodiment, which establish the organization for which 
the standard is being established, the hierarchy within 
that organization, and the amount identifier to which the 

15 standard applies. After the organization, hierarchy, and 

amount identifier have been established, a standard may 
be set for any or all points in the hierarchy as block 
666 portrays. The standard assignment for any point on 
the hierarchy may be changed or an assignment may be made 

20 for any point at any time after the standard has been 

defined. Block 668, therefore, conceptually depicts that 
once the standards have been established, a background 
process compares the standard to actual exposure and 
produces a variance or limits exceeded reports. 

25 Targets and limits may be expressed as a fixed 

amount or as a percentage of the portfolio being managed. 
Targets represent amounts to be achieved for the desired 
levels of exposure permitted or recommended. Both 
targets and limits can be established within the 

30 standards management function of the Credit Risk System 

(CRS) . Examples of targets may be the following: targe, 
10% of exposure to be in a particular state. Obtain 
S3, 000, 000 in new student loans for each new university 
or college signed up during the year. Examples of 

35 limits: Agricultural loans should not exceed 15% of 

total commercial loans. Customer exposure should not 
exceed S75 million to any single customer. Loans to 
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insiders should not. exceed 5% of the bank's total loans 
without prior approval of the board of directors. 

Conceptual illustration 670 of FIGURE 3 9 shows the 
concept of a desired level of exposure as depicted by 
bulls eye 672 of target 674. The standard maintenance 
definition process of the present embodiment also 
indicates where certain limits have been exceeded, where 
limits are depicted conceptually as a fence 676. 
Once the limits have been established, the portfolio is 
' continually reviewed and evaluated to ensure conformance 
with the prescribed risk tolerance limits. Actual 
exposure amounts are compared to the appropriate limits. 
Limits that have been exceeded are reported so that 
corrective action can be taken to minimize the risk 
associated with the identified portfolio concentrations. 
Target amounts are compared to actual balances to measure 
the institution's performance in achieving the desired 
levels of exposure. Variances from targets are reported 
on a periodic basis. 
0 In the present embodiment, standards are created 

using a series of a user interfaces or windows to define 
the standard. The data required in the design and 
concept of the windows is similar to those required to 
create a risk report using the present embodiment. 
5 Standards may be assigned as an amount or as a percent . 

The standards are assigned as a percent of the standard 
"amount by calculating its percent of a total exposure 
amount for the standard. 

The standard reports produced by the background 
0 processes are (1) a report that limits have been exceeded 

when the actual exposure of the financial institution has 
exceeded a defined limit, (2) a standard variance chat 
has been exceeded when the actual exposure is either 
above or below a defined amount, and (3) a detailed 
5 reconciliation report which provides the detail that 

individual amounts selected for comparison to the 
standard. 
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After the standards process occurs, standard 
management reports are produced by the system of the 
present embodiment. As such, FIGURE 40 shows the batch 
process flow 680 that the present embodiment performs. 
In particular, batch process 682 receives information 
from ledger data store module 684, control card input 
686, and segmentation data store the files 688. The 
output from batch process 682 includes reconciliation 
reports 690, exceeded reports 692 and variance reports 
' 694. Batch process 682 compares the actual exposure to 
the standard and produces reports of the variances 
between the two. The batch process can be run multiple 
times in the reporting period. 

FIGURE 41 shows a standard variance report that the 
present embodiment may provide. The standard variance 
report of FIGURE 41 identifies actual exposure amounts 
that vary from the defined standard amount. This report 
is ^produced by batch process which is run at request . 
The "actual exposure" amount is the amount on the ledger 
that matched the criteria for the standard (i.e., a match 
on organization, amount, and hierarchy. The "standard 
amount" is the amount entered on the assignment window as 
an amount or is calculated as a percent on the amounts on 
the ledger which match the organization, amount, and 
hierarchy. The "variance amount" is the difference 
between the actual exposure amount and the standard 
amount, i.e., the actual exposure amount minus the 
standard amount. The "variance percent" is the difference 
between the actual exposure and the standard amount 
divided by the standard amount . 

The present embodiment may also produce a standard 
detailed reconciliation report that displays all amounts 
that were selected and accumulated for comparison to a 
standard. This report is produced when either a variance 
or limits report is produced. The report is requested on 
the standard window. The individual ledger records that 
match a hierarchy point which has a standard assignment 
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are printed with the system of the present embodiment 
including a total for each hierarchy. 

FIGURE 4 2 shows the standards management and data 
flow diagram 700 that provides the primary processing 
functions and data flows within the standard management 
facility of the present embodiment. As data flow diagram 
700 illustrates, on-line input 702 is received by 
standards definition, selection, and assignment module 
704 to produce maintenance journal 706, MSS definitions 
' and relationship file 708, MSS hierarchies files 710 and 
standards data 712. Standards data 712 goes to report 
-generation module 714, which also receives input from CRS 
ledger 186. Outputs from report generation module 714 
include, as already described, standard variance report 
716, standard detail reconciliation report 718, and 
limits exceeded reports 720. 

FIGURE 43 shows standards maintenance, selection, 
and assignment processing flow diagram 730. In process 
flow diagram 730, standard maintenance window 732, 
standard selection window 732, and standard assignment 
window 73 6 may be used to provide inputs to standard GUI 
program 738. Standard GUI program 738 feeds risk 
standard maintenance at its module 740, which provides 
input to database interface module 742 . The output from 
_ database interface module 742 includes standards 
definitions tables 744 with which database interface 
module 742 communicates data and EMS maintenance journal 
746. Also, database interface module 742 receives input 
from customer definition table 748, instrument definition 
table 750, amount definition table 752, and segment 
category hierarchy table 754. Furthermore, database 
interface module 742 receives inputs from hierarchy 
definition table 756, customer hierarchy table 758, 
organization hierarchy table 760, product hierarchy table 
762, amount hierarchy table 764, segmentation category 
definitions table 766, organization definitions table 
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768, and product definitions table 770 in the present 
embodiment . 

CRS ledger 186 is the basis for checking defined 
standards and limits against the actual ledger item 
amount in process flow 73 0. The standard maintenance 
portion of processing flow 73 0 begins, therefore, with 
the setup of standards using standards windows 732, 734, 
and 736. This process is handled with the standard GUI 
program module 736 that supports windows 732, 734, and 
^736. When a standard is being defined, a select option 
on the user interface allows the user to proceed to the 
standard selections window 734 and the assign option 
allows the user to proceed to the standard assignment 
window 736. The standard selection is the selection of a 
hierarchy type and hierarchy identifier to which the 
standard applies using the standard selection window. 
Hierarchy types are customer, organization, product, 
amount, and segmentation category. This process is 
handled with the use of interface modules that support a 
particular window . 

The standard assignment portion for processing flow 
73 0 is the assignment of an amount of percent to each 
hierarchy point that has been selected from the standard 
selection window. This process is handled with the user 
interface modules that support the standards assignment 
window. Standard assignment uses these amounts or 
percentages in the calculation of standard variances and 
limit accesses. 

FIGURE 44 shows the process of checking defined 
standards and limits against actual ledger items as well 
as the reporting process for the standards facilities of 
the present embodiment. FIGURE 44, process flow 780 
indicates CRS ledger table 782 providing actual ledger 
amounts to database interface modules 742. Report 
processing parameters 784 provides input to standards 
checking/reporting module 786. In addition, standards 
definitions table 744, hierarchy definitions table 756, 
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customer definitions table 748, and instrument 
definitions table 750 provide inputs to database 
interface module 742 for standards checking/reporting. 
Furthermore, for this same processing flow, customer 

i hierarchy table 758, organization hierarchy table 760, 

product hierarchy table 762, amount hierarchy table 764, 
and segmentation category table 756 provide inputs to 
database interface modules 742. The output from 
standards checking/reporting module 786 includes standard 

3 • variance reports strings 788, standard detail 

reconciliation report string 790, and standards limits 
exceeded report string 792. These outputs go to 
standards management report driver 794 for producing 
standard variance report 716, standards detail 

5 reconciliation 718, and standards limits exceeded report 

720 . 

The standards variance report 716 lists all 
variances of standard targets versus actual exposure 
calculations. Variances in both directions (i.e., over 

0 and under a particular standard) are reporting for all 

defined standard targets. Standards detail 
reconciliation report 718 lists all detail items (i.e., 
ledger rows) that were consolidated to determine 
variances from defined standards. This report provides 

15 supporting detail documentation for standards variance 

report 716 and standards limits exceeded report 720. The 
report is generated for a specific variance or target 
report on a request. The standards limits exceeded 
report 720 lists risk exposure points and amounts that 

JO exceed defined standard limits. In addition to providing 

these reports, standards checking/report processing flow 
780 also updates the standards definition and standards 
assignment databases by on-line processes. FIGURE 4 5 
shows an example of the standard assignment hierarchy 

3 5 points usable with the system of the present embodiment 

including the committed exposure and loans outstanding 
hierarchy points. The individual hierarchy points are 
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displayed on a user interface such as a window. After 
point is selected, a standard may be entered as either an 
amount or a percent. A standard may be assigned for all 
or selected hierarchy points may be displayed. If the 
standard selection is for organization hierarchy, an 
assignment can only be made for hierarchy points 
subsequent to the organization selected on the standard 
user interface. After a standard has been defined, 
advanced process of the present embodiment compares the 
- standard to be actual and produces the variance and 
limits exceeded reports. 

FIGURES 46 through 49 illustrate ledger 800 for 
showing actual exposure amounts that may be selected by 
the system of the present embodiment. If the actual 
exposure amounts match the criteria established for the 
standard, the actual exposure amounts may be selected. 
In other words, the organization must match the standard 
organization or be a subordinate organization in the 
organization hierarchy. Also, the amount must match the 
standard amount or be a subordinate amount in the amount 
hierarchy. Furthermore, the instrument must have a data 
store match on the standard hierarchy. FIGURE 4 6 shows 
the credit risk ledger amounts that may be selected. 
FIGURE 47 shows the standard percent calculations usable 
with the present embodiment. 

FIGURE 4 8 illustrates the standard amount 
calculations that the present embodiment provides. If 
the standard assignment is established as a percent, all 
ledger amounts with matches on the standard organization 
and amount hierarchy are selected and the amounts are 
totaled. The assignment percents are converted to 
amounts by multiplying the total of amounts selected by 
the percent. FIGURE 4 9 shows an example of the standard 
definition where the organization is "FNB North," the 
amount is "used exposure," and the hierarchy is "customer 
sales size." Each record selected in the standard process 
is compared to the hierarchy points. When a match is 
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found, the amount of the record is accumulated. After 
all records have been matched, the accumulated amounts 
are compared to the standard amounts and variance and 
limited reports are produced. 

FIGURE 50 illustrates one embodiment of the logical 
data model 810 for the present embodiment of the 
invention. In logical data model 810, each block, such 
as hierarchy block 812, represents a data structure 
having one or more associations with another data 
structure such as customer hierarchy data structure 814. 
Each line, such as line 816, indicates a relationship 
between the data structures that it connects. At the end 
of each line is a mark indicating the type of 
relationship between two data structures. For each 
connecting line, a fanned or triangular end means that 
there are many data elements within a data structure that 
may be associated by the connecting lines. An 
intersecting tick mark, such as tick mark 820, indicates 
that only one data element within a data structure 
associates with a line such as line 822. A second tick 
mark, such as tick mark 824, indicates that the 
connection is required. A circle, such as circle 826, 
indicates that the connection is optional. Thus, a 
double tick mark combination, such as double tick marks 
828, indicate that there is only one connection and one 
connection is required whereas a circle plus a fanned 
end, such as combination 830 indicates that there are 
many optional connectors between the data structure and 
the associated line. 

Although the invention has been described in detail 
herein with reference to the illustrative embodiments, i 
is to be understood that this description is by way of 
example only and is not to be construed in a limiting 
sense. For example, the following exemplary modificatio 
is well within the scope of the present invention. It i 
to be further understood, therefore, that numerous 
changes in the details of the embodiments of the 
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invention and additional embodiments of the invention, 
will be apparent to, and may be made by, persons of 
ordinary skill in the art having reference to this 
description. It is contemplated that all such changes 
and additional embodiments are within the spirit and true 
scope of the invention as claimed below. 
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vm;VT IS CT AIMED IS: 

1. An electronic credit risk determining and assessing 
method for use in a data processing system having a 
plurality of interactive workstations and for providing 
credit risk information necessary for managing on and off 
balance sheet credit risks in at least one financial 
institution, said method comprising the steps of: 

staging data from a plurality external source to 
' form staged data; 

establishing a plurality of definitions associated 
with said staged data to form defined stage data; 

relating said defined staged data to said plurality 
of definitions to form related and defined staged data; 

establishing a plurality of risk rating data 
structures, said plurality of risk rating data structures 
comprising current and historical risk ratings associated 
with said related and defined staged data; and 

calculating a plurality of financial performance 
measurements associated with said related and defined 
staged data structures. 

2. The method of Claim 1, further comprising the 
step of establishing a plurality of standards data 

> structures for comparing to said risk rating data 

structures for determining differences between said 
standards data structures and said risk rating data 
structures to derive a set of target financial 
performance measurements . 

3 

3. The method of Claim 1, further comprising the 
step of associating a spreadsheet facility with said risk 
rating data structures and said financial performance 
data structures. 

5 

4. The method of Claim 1, further comprising the 
step of assigning a plurality of segmentation dimensions 
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to generate related and defined staged data segmentations 
according to predetermined characteristics of said 
defined staged data. 

5. The method of Claim 1, wherein said electronic 
credit risk determining and assessing may be performed 
independently of other financial methods performed with 
said data processing system, 

6. The method of Claim 1, further comprising the 
step of providing historical data relating to credit 
risks as a portion of said data from said plurality of 
external sources. 

7. The method of Claim 1, wherein said relating 
step further comprises the steps of relating said 
determined staged data for customers, instruments, 
officers, and organizations associated with said at least 
one financial institution . 
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8. An electronic credit risk determining and 
assessing system for use in a data processing system 
having a plurality of interactive workstations and for 
providing credit risk information necessary for managing 
5 on and off balance sheet credit risks in at least one 

financial institution, comprising: 

a data staging facility for staging data from a 
plurality external source to form staged data; 

a definitions data structure for establishing a 
0 " plurality of definitions associated with said staged data 
'.-to form defined stage data; 

a relationships data structure for relating said 
defined staged data to said plurality of definitions to 
form related and defined staged data; 
5 a risk rating data structure generating facility for 

establishing a plurality of risk rating data structures, 
said plurality of risk rating data structures comprising 
current and historical risk ratings associated with said 
related and defined staged data; and 
0 a financial performance calculating facility for 

calculating a plurality of financial performance 
measurements associated with said related and defined 
staged data structures. 

25 9. The system of Claim 8, further comprising a 

plurality of risk rating data structures, said plurality 
of risk rating data structures comprising current and 
historical risk ratings associated with said related and 
defined staged data. 

30 

10. The system of Claim 8, further comprising a 
plurality of standards data structures for comparing to 
said risk rating data structures for determining 
differences between said standards data structures and 
35 said risk rating data structures to derive a set cf 

target financial performance measurements. 
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11. The system of Claim 8, further comprising a 
standards data structures generating facility for 
establishing a plurality of standards data structures for 
comparing to said risk rating data structures for 
determining differences between said standards data 
structures and said risk rating data structures to derive 
a set of target financial performance measurements. 

12. The system of Claim 8, further comprising a 
.spreadsheet associating facility for associating said 

risk rating data structures and said financial 
performance data structures with a spreadsheet 
application facility- 

13. The system of Claim 8, further comprising a 
segmentation dimensions generating facility for 
generating a plurality of segmentation dimensions to 
generate related and defined staged data segmentations 
according to predetermined characteristics of said 

0 defined staged data. 

14. The system of Claim 8, further comprising 
instructions for performing said electronic credit risk 
determining and assessing steps independently of other 

5 financial methods performed with said data processing 

system. 

15. The system of Claim 8, further comprising a 
historical data structure for relating to credit risks as 

0 a portion of said data from said plurality of external 

sources . 

16. The system of Claim 8, wherein said 
relationships data structure further comprises a sez of 

5 instructions for relating said determined staged daza for 

customers, instruments, officers, and organizations 
associated with said at least one financial institution. 
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10 



17. An method for forming an electronic credit risk 
determining and assessing system for use in a data 
processing system having a plurality of interactive 
workstations and for providing credit risk information 
necessary for managing on and off balance sheet credit 
risks in at least one financial institution, comprising 
the steps of : 

forming a data staging facility for staging data 
from a plurality external source to form staged data; 
forming a definitions data structure for 
^^establishing a plurality of definitions associated with 
^said staged data to form defined stage data; 

forming a relationships data structure for relating 
said defined staged data to said plurality of definitions 
15 to form related and defined staged data; 

forming a risk rating data structure generating 
facility for establishing a plurality of risk rating data 
structures, said plurality of risk rating data structures 
comprising current and historical risk ratings associated 
with said related and defined staged data; and 

forming a financial performance calculating facility 
for calculating a plurality of financial performance 
measurements associated with said related and defined 
staged data structures. 



20 



25 



30 



18. The method of Claim 17, further comprising the 
step of forming a plurality of risk rating data 
structures, said plurality of risk rating data structures 
comprising current and historical risk ratings associated 
with said related and defined staged data. 



19. The method of Claim 17, further comprising the 
step of forming a plurality of standards data structures 
for comparing to said risk rating data structures for 
35 determining differences between said standards data 

structures and said risk rating data structures to derive 
a set of target financial performance measurements. 
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20. The method of Claim 17, further comprising the 
step of forming a standards data structures generating 
facility for establishing a plurality of standards data 
structures for comparing to said risk rating data 
S structures for determining differences between said 

standards data structures and said risk rating data 
structures to derive a set of target financial 
performance measurements . 

0 ' 21. The method of Claim 17, further comprising the 

step of forming a spreadsheet associating facility for 
associating said risk rating data structures and said 
financial performance data structures with a spreadsheet 
application facility. 

5 

22. The method of Claim 17, further comprising the 
step of forming a segmentation dimensions generating 
facility for generating a plurality of segmentation 
dimensions to generate related and defined staged data 

0 segmentations according to predetermined characteristics 

of said defined staged data. 

23. The method of Claim 17, further comprising the 
step of forming instructions for performing said 

5 electronic credit risk determining and assessing steps 

independently of other financial methods performed with 
said data processing system. 

24. The method of Claim 17, further comprising the 
0 step of forming a historical data structure for relating 

to credit risks as a portion o£ said data from said 
plurality of external sources. 
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25. The method of Claim 17, wherein said 
relationships data structure forming step further 
comprises of forming a set of instructions for relating 
said determined staged data for customers, instruments, 
officers, and organizations associated with said at least 
one financial institution. 
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